I'm curious how this handles changes within nixpkgs itself. For example, if developer A has nixpkgs version 111, and developer B has nixpkgs version 222, and th

I'm curious how this handles changes within nixpkgs itself. For example, if developer A has nixpkgs version 111, and developer B has nixpkgs version 222, and they both attempt to build a Haskell project depending on "libxml", they may compile against different versions of libxml (or worse, an older version of libxml might be incompatible with the Haskell code). Nixpkgs solves this itself by "owning" the entire dependency tree. That is, if there's a definition in nixpkgs that requires libxml, you can bet it works with the libxml derivation defined in that same nixpkgs. If not, there might be libxml1, libxml2 derivations defined. In practice, using the ~latest version of everything, or whatever nixpkgs happens to have, usually works well. I started moving toward building my own nixpkgs distribution, which included a vendored copy of nixpkgs at a specific version (rather than whatever version was available at the time you downloaded it), combined with a few customizations for specific (older) versions of, say, libxml. This ensured multiple developers could download things months apart and still expect everything to work. (nixpkgs changes somewhat rapidly.)