AFAIK, Nix even has a testing framework, where you can start a VM and simulate various actions inside it. All described by a single Nix script. I haven't explored it myself yet, but I understand it's used for unit-testing various Nix packages.

+1 for nix. _nix-shell_ is a great way to get stuff up and running without having to wrestle with the container boundry.

I don't work on projects where Docker is useful in production, but I've found it tremendously useful in continuous integration. It guarantees a reproducible environment, which a VM could do, but just as importantly it documents how to produce that environment from scratch. I've found that hugely valuable.

I've always liked the idea of Nix but I've never used it. How easy is it to extract and understand the details of the environment you've constructed to build your project?

> Docker... documents how to produce that environment from scratch. I've found that hugely valuable.

> How easy is it to extract and understand the details of the [Nix] environment you've constructed to build your project?

The "extract" part is easy: Nix uses a declarative language to describe the environment, so in that sense it's like docker, but more fine-grained: each package is built in isolation, and installed to a read-only filesystem.

As far as "understanding the details", it depends on what you want to know. You can use "nix-shell" to enter a build environment in a shell, e.g.

    nix-shell -E 'some Nix expression'

will enter the build environment of 'some Nix expression',

    nix-shell -p 'some Nix expression'

will create an environment with 'some Nix expression' installed, etc.

For example, I'm currently tracking down a space leak in a Haskell program by running the following command after each edit of the source code:

    nix-shell -p 'with import <nixpkgs> {}; profiledHaskellPackages.callPackage (runCabal2nix { url = ../myTester; }) { myDependency = profiledHaskellPackages.callPackage (runCabal2nix { url = ./.; }) {}; }' --run 'tester +RTS -M100M -xc'

The command 'tester +RTS -M100M -xc' is a Haskell program which dies if it uses more than 100MB of heap, exposing the space leak and dumping a stack trace.

This will be run in an environment containing Haskell packages built from the source code in "./." (the current directory, for "myDependency") and "../myTester" (for the "tester" command). These packages and all of their dependencies will be built with profiling enabled.

Running this command over and over will just re-use the previously-built environment. If I edit the source in ./. or in ../myTester, Nix will notice that the hashes have changed, rebuild the packages and their dependents and make a new environment using those. This makes it easy for me to test potential fixes.

the problem is docker builds aren't really reproducible; e.g. if you're using ubuntu, you have to do apt-get update or your apt-get installs will fail with 404s.

i also haven't used nix, but i hear it truly solves the problem.