Disclosure: I work at Microsoft / Azure.<p>I am a dev container addict. I work on tons of different projects across languages, and it's so nice for the dev environment to just work (mostly- if it doesn't, it's because of M1 issues). I also love Github Codespaces (that uses dev containers), I've been using it for all my workshops lately and attendees tend to prefer Codespaces instead of local dev.<p>If you're looking for example dev containers, I've got a bunch of repos linked from my read me that have support:
<a href="https://github.com/pamelafox">https://github.com/pamelafox</a><p>The trickiest ones have involved databases, but I was happy to be able to get PostgreSQL running inside the container, along with an admin for it!
We did a Youtube stream showing that here:
<a href="https://t.co/0Kl57Ew46C" rel="nofollow">https://t.co/0Kl57Ew46C</a><p>Yesterday I got docker-in-docker working as I'm running a Docker workshop today and want Codespaces to be an option. So cool. That's at
<a href="https://github.com/pamelafox/flask-surveys-container-app/tree/main/.devcontainer">https://github.com/pamelafox/flask-surveys-container-app/tre...</a>
The way I see it - it's a really nice way to make reusable modules out of your Docker files (e.g. we need to install a tool and we need to run apt-get + some config, etc). And a simpler, JSON syntax to apply those modules on top of a base image.<p>I love the experience so far, we've done a few features (modules) - e.g. this one to install `nvtop` to see GPU utilization [0]<p>The whole CUDA + nvtop + (some other tools) setup for a project to be run on a remote machine (e.g. via VS Code) becomes like this [1]<p>And that's enough to run ML training on GH Codespaces with GPU support. Super cool experience.<p>[0] <a href="https://github.com/iterative/features/blob/main/src/nvtop/install.sh">https://github.com/iterative/features/blob/main/src/nvtop/in...</a><p>[1] <a href="https://github.com/shcheklein/hackathon/blob/main/.devcontainer.json">https://github.com/shcheklein/hackathon/blob/main/.devcontai...</a>
I’m a huge fan of devcontainers. If you use VS Code or Codespaces, it makes it really easy to do a remote environment exactly the same for everyone. I use them in workshops and it’s great.<p>It’s an open standard and we’re starting to see more members of the community adopt it or integrate support into their stuff too (including some larger Nix players like devenv and Jetpack.io) and I really hope others adopt it too. For me, for however many years I’ve been using these (it’s at least 2 but it could be longer, time is a circle), it has definitely improved my QoL.<p>Disclosure: I work at GitHub which uses devcontainers in Codespaces and I used to work at Microsoft which developed this and used it with VS Code and the amazing VS Code remote extension.
My coworker uses this a lot at work to solve the problem of keeping different software versions consistent across developer machines on the team. Being by Microsoft, this dovetails really well with Visual Studio Code. I find the CLI to be okay I guess for something written in JavaScript. I prefer ASDF generally[1] for solving this problem, since there's always a lot of fiddling you have to do with containers, but this is more cross platform so there's that.<p>1: <a href="https://asdf-vm.com" rel="nofollow">https://asdf-vm.com</a>
I don't get why I need this rather than just a plain container/dockerfile. That is how I work today and that is my "devcontainer", no separate markup needed.
containers.dev is a spec created and only implemented by Microsoft (in Visual Studio [Code] and GitHub Codespaces). Tool vendors (of IDEs) decided to go to war, instead of collaborating, it seems. XKCD's "standards" comic seems to apply [0] here.<p>As I've blogged about here [1], there are other specs such as Devfile.io or GitPod's proprietary gitpod.yml file.<p>[0] <a href="https://xkcd.com/927/" rel="nofollow">https://xkcd.com/927/</a><p>[1] <a href="https://www.augmentedmind.de/2022/10/30/container-based-development-envs/" rel="nofollow">https://www.augmentedmind.de/2022/10/30/container-based-deve...</a>
Aside of comments about the containers spec, I'd like to share that codespaces-like environments are huge for me.<p>Being able to able to open an open source project on the go just by launching a codespace is no small feat.<p>I have also been recently programming in quite heavy environments which my computer could not handle (especially when screen sharing) properly so launching the environment in a remote cloud instance with 8 core and 16GB of ram was useful.<p>All my personal projects are developed in codespaces too to minimize time I spend setting up or syncing those to lower the friction as much as possible. Going from desktop to tablet to my laptop all I need to do is to launch the codespace.<p>I hope other vendors will contribute to the spec, there's nothing to benefit here from every cloud implementing their own spec, they will eventually lose to Microsoft rather than leverage the spec.
Your choice of dev environment should be driven by product requirements, period. Dev environments should dogfood the production supply chain <i>as much as possible</i>, meaning use the same base container/OS/toolchain/etc that will be used in production.<p>Otherwise you are going to miss bugs/vulnerabilities and spend a lot of time keeping dev/prod provisioning in sync.<p>Deploying to containers/k8s? Develop in a container.<p>Deploying to VM/bare metal? Develop in a VM (Vagrant).<p>Developing a portable library? Nix may be a good fit.
Tbh I feel that all this everything version pinned and containerized ultimately is inducing lot of fragility in the ecosystem, and makes it more and more difficult to work with wide range of tools. Reminds me of smalltalk images in one way, and in other way of one enterprise gig I did where using some ancient IBM IDE and runtime was required because the project setup was too crusty to trust it to work any other way.<p>I long for the opportunity where the software I develop would work with plain vanilla Debian stable and would require nothing else.