Nix along with its build and run-time dependencies.
A package that is unmaintained upstream, and especially when the author says it should no longer be used. So e.g
In my opinion that should not go in, at all. If it does happen to go in, it should be marked broken. By now it seems it is maintained though.
It’s cheap to press the Merge button, but the initial reviewing and afterwards maintaining are not. Unless it’s a trivial package with few dependencies.
I think it is fine if someone (or preferably more than one) open a PR to introduce guidelines for in the Nixpkgs manual. It can then be discussed there, and you’ll see how many people are interested in working on it. It may of course happen that a NixOS/RFC will be requested. Anyway, what I am saying is, the best way to get this to happen is coming up with an initial proposal that can be discussed and put in place. As soon as a group of interested people forms and do things, then I doubt anyone will be blocking you.
Absolutely. The suggested sets are I think too specific given the amount of users we have. I would widen it a bit, to say “scientific computing” and “gaming”. If we have an overlay for each that follows the same branching/releasing as Nixpkgs, then I think that could work very well. Discoverability and ease of use are key, and that’s where Flakes may play an important role. I am a bit skeptical towards Flakes providing libraries though but I envision these package sets provide both a Flake and an overlay.
I think it would not be a bad idea to split the scientific computing bits out of Nixpkgs into a separate repo. Core packages would still remain in Nixpkgs (e.g. blas, lapack, numpy) but things like Tensorflow would move out.
Note though, that when setting up these kind of package sets, that we need a good way to set up CI for it as well, like an ofborg instance.