Docker gurus: I am not familiar with docker, any immediate problems stand out about the idea of trying to make customized vim into a redeployable docker image for easy portable usage?

Thought I might side step having to save config and reinstall stuff (still got to pimp it out the first time)

you don't have to customise vim.

just do `alias vim=nano`

Nope. Nope. Nope. Don't do that

Just share the config file

While possible - the question is:
Why?
Ypu want to use vim across many systems, to do what?

Some people probably disagree with me but I think that is a poor usecase for docker. Sounds more like a configuration management issue. You can use config managers like Nix or Ansible for that and it would be easier to update and deploy everywhere.

Not a docket guru but the only thing I could see going wrong is if you have installed Vim plugins and they cause potential errors when creating containers from the image, but otherwise I don’t think there’s an issue. Why not just include the config file in the image and config/build Vim with your Run task in the dockerfile?

You could, but your storage is also isolated, so you'll have to let your data into the container at startup.

docker -it -v /path/to/data:/data myvim

Portable usage: Static builds.

Thats it.

Docker is *far* to complicated for that.

@lungdart Yeah. No.

The main problem with using Docker like this, is how to correctly set file permissions using the ACL.

By default, Docker runs as Root inside its own container - Security nightmare btw. So - if you use an editor for files on a mounted volume - any file you edit will be set to be owned by root:root.
In order to match the gid:uid of the files correctly between container and host - you need to either be ok with the mounted file system to be owned by root on the host (unlikely), or make the container default user Ids to match the host user Ids.

And this should be customized for each system you are going to run the conatiner on - making the whole Docker container approach irrelevant, as each user will need its own custom image.

I occasionally have this thought as well for development environmens in general, but the steps required to make it work far outweigh the benefit. It would be portable, but only for hosts that have been set up to accommodate it. Compare this to a vimrc dotfile that you can have at a public url and polish over time.

I did sort of do this for a project that needed a very specific version of node and python, and I didn't want to start messing with nvm and venvs. One of the issues I ran into was that the editor was not able to connect to the language server as "localhost" in a docker context can be ambiguous, and it was more than a day to make that work. I was also not able to clone the repo from the container as the repo is only accessible from vpn, and it was not obvious how to allow the container to use the host's virtual network device. I ended up cloning to the host and setting that as the remote from the container.

This is all fixable and viable if the requirement is there, but it's not a way to streamline a general way of making IDEs portable.

That all said, it's still fun and a good incentive to learn about docker if that's your goal.

@magicMirror you can pipe up guid and uid to the container for this purpose. Linuxserver.io images use this technique.

Lots of people are using docker for development environments these days, and they do it just fine. It's a valid approach.

You can but as people say, it might just be easier to git and store/restore your vim config there.

If you DO want do that though. You will need to prepare your full vim config, build a dockerfile which copies that over into a docker image, then upload the image somewhere like dockerhub.

When running the image you need to mount the location you want to edit as a volume. You can set that up once with docker-compose.

Docker runs as root so any new file which gets created by vim in your docker will have root as an owner. You can avoid this by specifying which user to run as, or just use Podman.