Devenv.sh: Fast and reproducible developer environments using Nix

Strictly compared to containers, the big advantages are reproducibility and lower overhead.

Overhead: Windows and macOS can't run Linux-based containers natively. Instead, there's always a full Linux virtual machine running in the background acting as an intermediary and host for your containers. Nix can conjure arbitrary native development environments on a per-command or per-terminal basis, giving you all the performance of directly running tools without the risk of clashing with systemwide software.

Reproducibility: Nix provides much stronger guarantees about the exact versions of software you're running. It effectively gives you a lockfile for your entire dependency chain, all the way down to libc. Containers tend to be more stateful: everyone on your team may be using the same Dockerfile, but if you build an image from it two weeks apart, you're probably going to get very different outputs due to things like your apt-get update step returning new versions of packages. This doesn't happen with Nix.

The beauty is that this isn't either/or; you can actually use Nix to generate OCI container images which are thus fully specified and repeatable.

Big drawback of devbox is that you cannot pin packages to specific SHA, which is quite a big limitation when it comes to versitality. I think you can do that on devenv.sh.

I avoid "developer environments" because they are different from production environments and that leads to bugs that don't show until the application is in production. "But it worked in development" problems waste a lot of time.

Putting "developer environment" in the name of this tool perpetuates bad practices.

Any tool that constructs environments for applications should be general enough to handle both production and development.

Seems like Nix is having a bit of a moment. After devbox[1] was released I started looking into Nix, and there's a lot happening.

I'm staying away from these Nix wrappers and learning how to do some basic nix-shell work, myself. Until it's proven the wrappers are adding real value, not just trying to hide scary scary Nix from devs who only feel safe in YAML files.

For the curious, this post[2] describes mixing Nix and Docker. And this[3] is a pretty decent tutorial on using Nix itself for this use case (consistent developer environments). Without going full NixOS, setting up a shell.nix with some OS-level environmental dependencies is a great way to dabble.

It seems there may be a sensible reaction away from "Dockerise all the things" for development at least, e.g. this blog post[4]. There are real downsides to containers for development, even though using things like `rvm`, `nvm` and `venv` were also a pain.

We've run into issues ourselves with developers starting to use the new M1 Macs - we've still not figured out how to make filesystem mounting fast yet. There seem to be other advantages to running more things locally, like simpler configuration of debuggers etc. (EDIT for clarity: the issues were with Docker, not Nix, hence the reference to filesystem mounting. Nix == "running more things locally".)

But taking a broader view, while containerising apps with complicated dependencies is a win, we really don't need to pretend that production and dev are actually identical environments. For example, only one of these environments needs a compiler. Once you acknowledge that the developer environment shouldn't be fully identical to prod, then you can start to think about what things do need to be the same, what can differ, and what your actual requirements are.

[1]: https://www.jetpack.io/devbox/

[2]: https://ghedam.at/15502/speedy-development-environments-with...

[3]: https://nix.dev/tutorials/declarative-and-reproducible-devel...

[4]: https://blog.testdouble.com/posts/2020-02-11-the-slippery-sl...

You don’t want to deploy your development tool chain to your production environment, ergo, you want a development environment.