I think local reproducible dev environments is a great and less-intense way to get into Nix (the package manager)! https://devenv.sh/ is built on top of Nix as well to make it more approachable and user friendly for exactly your use case.

I’ve been toying with the idea of using Nix for dev environments at work. What does devenv add on top of Nix?

Edit: And if you know, how does it differ from devbox?

I haven't used devenv or devbox, I've taken the full Nix/NixOS plunge - sorry I can't be more helpful! I've just seen devenv on HN and glanced over its homepage and saw that it was based on Nix but supposed to be easier to use. If you want to jump straight to Nix itself, more power to you! There's a big learning curve, but I have found it very worth it.

I would note that while Nix is very well designed, and may be incredibly useful in untrusted dev environments, it should not be used to compile anything that touches production. Nix got where it is so quickly by mostly ignoring basic supply chain integrity like author package signing. It is always one compromised Github account or single dev workstation away from a massive supply chain attack.

Nix, NPM, Brew, Pip, etc all have basically the same blind trust security posture and should thus not be trusted. I generally suggest Debian in a container for a dual use dev/compile container made of signed/vetted/reproducibly-built dev/build/debug dependencies.

As someone who knows nothing about package signing and security, are you saying that Nix is about as secure as NPM?

Correct, and that is not a good thing.

I think containers (docker/vagrant/etc) are probably what you are looking for.

Just the other day I had to figure out an opaque problem with a vagrant image not working. It was very annoying, and wasted the entire time I had set aside for coding.

Did this happen when you have more than 5 microservices each one with its own database?

At a previous employer, there was a basically full-time team member (contractor like me, but long-term presence so it didn't matter much) working with configuration management. It was basically his job to keep the development environment working, and kept reasonably up to date.

That was done using VM images that he owned and maintained, which was not optimal for me, but there was also documentation laying out the steps needed to create the environment so it was possible to maintain a bare-metal clone of the official environment and use that. Good times!

Tools like Devbox: https://github.com/jetpack-io/devbox are making this way easier. Devbox is powered by nix, but it hides all of the complexity and makes it easier to use.

I ship a Dockerfile and Makefile with every single project that contains absolutely everything I need to build, test, and debug that codebase.

I cd to a project and run "make shell" and I am back in a docker container with every tool and the current working directory mounted in it with permissions all mapped 1/1, scripts in path, etc.

The only tools I need on a dev machine are an editor, a browser, a container runtime, and make.

I have my whole Linux desktop machine, two laptops and a few servers fully codified now in Ansible.

Everything is in there. Every library and piece of software, every config and preference. User creation (minus any sensitive data). Everything.

Made a bootstrap script I run on a fresh install, and then I can push the ansible config onto it from a raspberrypi ansible server on my LAN.

Wanted a different file system in december. Wiped the system, changed filesystems, resetup. Took less than 1 hour.

Isn't this what Microsoft is trying to solve with dev containers? https://containers.dev/

We had a session here where someone explained how you can use a docker container with VS code to have reproducible local env (for the whole team).

Seem like you never got on board the declarative-infra-as-code boat, it's actually rekindling my software flame, with things like docker-compose and NixOS, everything you ever work on can be stored as code, and set up with 0 effort.