Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
tosensei6400125dyou don't have to customise vim.
just do `alias vim=nano`
iiii9465125dNope. Nope. Nope. Don't do that
Just share the config file
magicMirror10695125dWhile possible - the question is:
Ypu want to use vim across many systems, to do what?
hjk1015749125dSome 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.
shovethisrant5644125dNot 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?
IntrusionCM15286125dPortable usage: Static builds.
Docker is *far* to complicated for that.
magicMirror10695125d@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.
ltlian2211124dI 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.
arekxv1054121dYou 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.