At my workplace, Guix's lack of macOS support takes away some of the benefit of using something like Nix or Guix as opposed to HVM solutions like Docker Desktop or Vagrant. I imagine this situation is unfortunately common.
For teams where GNU/Linux is the primary development OS, Guix seems like a great choice.
I set this up for my last company where we had all sorts of “works on my machine issues” and a needlessly painful onboarding experience. Local development became streamlined with this tooling BUT pre-apple silicon macs couldn’t handle running Docker like this. Glacially slow. We had a python monorepo with a bunch of services within it.
I am curious whether nix is an alternative / improvement for this. Was going down the nix road at first but an infrastructure team member steered me toward devcontainers instead and I’ve been pretty happy since!
FYI, I've helped set up StableBuild (https://www.stablebuild.com) to help pin stuff in Docker that's normally virtually impossible to pin (e.g. OS package repos, Docker base images, random files from the internet, etc.)
Different kind of rot. With nix and flakes, I can come back to a project 5 years later and as long as external dependencies (i.e. package sources) still available it will bring me back straight to that environment like it was yesterday.
If you have a Dockerfile from 5 years ago...well good luck building it today.
my point stands, it's still trying to lie about the meaning of the word rot. it's just as delusional as docker original "rotting software will run in 5yrs" argument... nothing there goes against rot
Containers are a great deployment target, but they're not really a great development environment for a few reasons (e.g., they're Linux-specific, so they require extra virtualization on non-Linux operating systems, the kind of isolation they provide is more of a hindrance than a help when it comes to working on your local filesystem, and for them to be useful you have to set up infrastructure to push and pull your private containers to and from).
Nix is a better fit for this, and when you're using Nix you can also have Nix generated containers for deployment. I think you can also use a container with Nix in to provide the devcontainers interface to devs who don't have Nix installed locally, and have it in turn use Nix against your project's flake to set up its environment.
IIRC, it uses what is defined for shell environment. Just instead of activating on your machine, it produces OCI image with that environment.
I have nixOS definitions that I can use to make a SD card image, overtake a running linux system via ssh, deploy to nixos via ssh, or deploy to a local system - all from one definition.
It (obviously) leverages Nix, which in turn means the environment is declarative and fully reproducible (not "reproducible" as in docker). Now, you can use just Nix's devShells, but with devenv you have a middleground between just Nix package manager and a full fledged NixOS module system. Basically, write out one line of code - and you've got your Postgres, another one - full linter set up for whatever language you're using, etc.
Can I also get the security/isolation benefits that a duly configured docker/podman can provide (container can only act on mounted volume, non-root user, other seccomp settings?).
I feel better doing my "npm install"s in such an environment (of course it's still not a VM – but that's another topic).
When I read about nix, reproducibility is a goal, but security/isolation is a non-goal.
So you can use them in conjunction (or alternation, if for some projects you're okay running without a container) without having to specify your development environments twice.
> I feel better doing my "npm install"s in such an environment (of course it's still not a VM – but that's another topic).
There are basically two kinds of integration you can do for a project with Nix, which I'll call deep and shallow. In shallow integration, you just have Nix provide the toolchain and then you build the project (manually, with a script, with a Makefile, whatever). This is pretty common and pretty easy, and gives you no protection from malicious NPM build scripts.
For deep integration, you can actually have Nix build your whole project. This has some downsides, like that it can't really handle incremental builds. It also imposes restrictions, like no network access by anything but Nix at build time, all packages are built by special build users with no homedirs and no perms to access anything, etc. When you do that kind of build/install, you do get some protection from crypto miners lurking in the NPM registry or PyPI or whatever.
My small team uses devenv for all our development environments and we really like it. Local DX is really important to me and to our team, which is a big part of why we've chosen Nix and devenv.
As we've started to use it more extensively, we've also found that we want to add some enhancements, work out some bugs, and experiment with our own customizations out-of-tree, etc. I'm happy to report here on HN that devenv is well-documented and easy to extend for Nix users who have some experience with Nix module systems, and that Domen is really responsive to PRs. :)