@sheepforce and I have summarized our efforts to package quantum chemistry packages in a peer reviewed article (open access):
M. Kowalewski, P. Seeber, “Sustainable Packaging of Quantum Chemistry Software with the Nix Package Manager”, Int. J. Quantum Chem. e26872 (2022).
The article itself is aimed to sell the concept to the theoretical chemistry community. However, it may also be of interest to everyone working with scientific computing or HPC applications.
Nix has been used for example at CERN to distribute software for LHCb
This is very cool 
Also, I found your explanation of the Nix package manager to be very clear - congrats!
I know that Guix has an explicit focus on HPC, could you comment on your choice of Nix instead of Guix?
I know that Guix has an explicit focus on HPC, could you comment on your choice of Nix instead of Guix?
The explicit focus is a strength of guix. My personal reasons for using nix instead are twofold: first, the nix community is much bigger and nix has many more packages (and nix is better up-to-date). This allows me to run not only scientific apps but also NixOS. Second, I like the nix language much better than scheme. The guix approach with scheme might be formally cleaner, but I do not want to type all these brackets.
The community aspect is certainly important for me, too. I am doing my scientific projects in Haskell and need the integration between the computational chemistry codes and Haskell. And it seems the Haskell and Nix community have much more overlap, than Guix and Haskell.
Because (looking at the end of a random .nix of mine) this
};
}
)
);
}
);
}
is so much better than this: ))))))) ?
I find it both amusing and sad that people criticize Lisps for the parentheses, when the parentheses are one of the core strengths of Lisps, and people who get over the initial eww and actually use Lisps, end up loving them. For one, the editing experience is so much better precisely because of the parentheses[1].
I find it almost as sad to see Nix being criticized for inventing its own Turing-complete language, that language having unfamiliar syntax, that language being functional, that language being lazy, and so on.
It’s not being functional or lazy or having a syntax that surprises Java programmers, that makes Nix difficult. It’s the vast vocabulary and the immensely complex, nasty, ugly, concern-cross-cutting problems that it is used to solve, combined with the fact that the documentation is mostly only useful if you already know what you’re doing.
The language itself isn’t a problem at all, so it’s unfortunate that so many people make the mistake of convincing themselves that the language is the cause of their Nix frustrations.
It’s a tragedy if Guix exists (and splits the manpower of the niche-but-absolutely-vital effort to bring declarative system management to the world) because some people thought Nix was a great idea but didn’t like the shape of the balanced delimiters used by the language.
[1] Anecdote time: That horrible [L]ost [I]n [S]uperfluous [P]arentheses syntax goes by the name of S(ymbolic)-expressions. Originally these were meant to be a low-level intermediate representation used only in the Lisp compiler, not fit for human consumption. The humans were meant to read and write M(eta)-expressions: stuff that non-Lispers would recognize as a programming language. But a couple of clowns implemented something that executed the S-expressions directly, everybody started using them, and decided that they preferred them to the M-expressions, so the the latter were abandoned and Lisp has been famous for its brackets ever since.
Have you had any thoughts on how the need to provide local licenses will interact with flakes?
Have you had any thoughts on how the need to provide local licenses will interact with flakes?
One idea to solve this issue is to create a private wrapper flake, which feeds a custom config to the overlay (including your license infos). We have an example here: