> 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.