definitely, I don’t want to start a flame war, but I am just looking for more information about the two different build system by somebody who is more experienced than myself.
I would also be interested in a thorough comparison. I have not used Spack, but I think their reference documentation is very good. The way to select packages on the cli seems to be a bit closer to the module system, and Spack can also use the module system.
They document how to use impure dependencies (such as mpi, openssl, blas) because it may make sense for security or computing reasons. Using impure dependencies is typically not done with Nix (except maybe on Darwin/OSX).
Considering their target audience (HPC) you can see the expressions typically have computing-related flags to quickly enable features, such as mpi. These things can be done, and are done with Nix in Nixpkgs as well. I do think the expressions are a bit less organized in Nixpkgs. On the other hand, Nixpkgs has 40 times as many packages.
Q. What are the differences between Spack and Guix? Is there a comparative list available
somewhere I can refer to?
See Concept: use any package version, post 31; Spack focuses on allowing you to build any configuration and flexibility. nix and guix don’t have packages with all the parameters spack has, also they require root to build. Spack packages are in python; spack does concretization (dependency resolution); nix/guix do not. Spack has more extensive compiler/arch/virtual dependency support. Spack binaries are relocatable, do not
require root.
The Spack repo also cites a paper from 2015, The Spack package manager: bringing order to HPC software chaos that does mention Nix at a few places (3 or 4 mentions) but its concise description of Spack’s architecture and behaviour makes it easier to do direct comparison with Nix than using the official Spack docs. (The paper sits behind a paywall unfortunately so you’ll have to find ways around it.)
There is also the flatiron/nixpack hybrid; Nix lang frontend and Spack backend, if I read that correctly.