Hacker News new | ask | show | jobs
by highmastdon 1095 days ago
Is it really like that? I expected a docker container having all the deps except for running the project which would be something that’s mounted as a volume. Then each container would spin up its own watcher to build/test/serve the project. And have a bash open to run additional commands.

Maybe my assumptions are wrong though…?
2 comments
CGamesPlay 1095 days ago
The first problem you'll encounter here is if you're using a language that keeps dependencies in a separate place (virtualenv, central cache location, etc.). You have to figure out how that works and mount that location as a separate volume, or else you'll be constantly recompiling everything when your container is recreated. Using a bind mount for the project files is also annoying because docker-compose makes no effort to sync your uid/gid, so you have all sorts of annoying permissions issues between local/container. And installing packages into your container that doesn't have an init process is... annoying at best. You can use sysbox to get one, but you're not really "just using docker compose" at that point.
link
PrivateButts 1095 days ago
That's the dream, but in my experience there are some thorns, and some things that just suck. Mostly these come from Windows, like a dev station using the wrong line endings, filesystem watchers not working if the project isn't on WSL storage, file permissions getting mucked up, etc. However, what is a pain in the butt is adding dependencies. Do you attach a shell and run npm in the container or try to do it on the host system. Do it in the container, and you'll have to make sure those changes make it's way back out, and that you rebuild the container the next time you launch it. Do it on the host, and you could run into cross platform issues if a package isn't supported on Windows, and you'll have to rebuild the container.

However, once you're aware of this, honestly it's not that big of a deal. Docker rebuilds are pretty fast nowadays, and you can use tools like just to make the DX a little easier by adding macros to run stuff in a container.

End of the day though, folks are all gonna have their own way of working, and I think dev containers could have an advantage for peeps doing remote development. It would be nice to have a system where our developers could dial in to a container with everything they need from anywhere they want to work.

link