Hi,
I’m constantly stumbling over packages, which
I think, NixOS needs some quality control for the packages to improve this.
My suggestion would be: Use an official and an unofficial/AUR-like channel:
One channel for all packages which are currently maintained, are tested to work, and have metainformation; and one channel for all the other, possibly outdated and broken packages.
What do you think, and how could we achieve this?
The quality of a package largely relies on the maintainer-ship of it, and how well it integrates with the nix isolation. For example, cmake support is excellent as we have way to specify good defaults, and don’t have rely on FHS for it to work. Python has a lot of leaky abstractions and although there is a lot effort to make the ecosystem polished, there is a mis-match in abstractions between python and nix which are painful in some situations.
There is, it’s call NUR: GitHub - nix-community/NUR: Nix User Repository: User contributed nix packages [maintainer=@Mic92]
If you want stability, please use the date release channels such as 19.09. If you’re fine with some breaking changes and would prefer everything to be much more up-to-date, then go with unstable 
There definitely could be a sprint for broken packages and those that don’t have any metadata.
As far as I can tell, the committers shouldn’t merge any packages that are broken or don’t have any metadata in the first place. And I believe for at least new contributions this is how things are happening.
However there is a problem with people being able to continue to contribute to nixpkgs because of mass influx of PRs.
The problem is: I’m using 19.09., but I’m constantly getting broken (and partly very very old) packages.
I’d like to have a channel, where the packages are
And changes to the nix-ecosystem should not break these packages (like the Qt-wrapper-changes silently broke many packages; if such a change is made, all packages in the tree should (ideally automatically) be tested against it, instead of silently causing broken packages and saying “if this change broke your package, please fix it”…).
I have previously suggested that we might want to extend the staging model to all PRs. That would at least make what you suggest feasible.
To claify: I’m not sure if this is something we should do or not. But worth considering.
I guess to some degree the possibilities depend on whether packages that “do not work” are failing to build, or build fine but still don’t work correctly.
I’m definitely not “blaming” you hardworking people and the people who spent precious time to comment on my pr but #77734 I didn’t add maintainers to meta and nobody commented. (I’m not blaimin, I’m just saying the practice could be more widespread)
Please see nixos lts discussion
We haven’t made adding a maintainer to modules mandatory. If you had written a package I can assure you that someone would have mentioned this.
your PR is a nixos module, most of those just have the maintainer in the meta section. Also, I’m not sure if modules are as “standardized” as are packages.
It’s crazy right now, I think ive been addressing 20-50 PRs a day, and the count keeps getting higher.
EDIT: addressing means commenting, reviewing, or merging. Not just merging
If the nixos foundation had enough money to employ people to do this, then these might be realities. As it stands, maintaining and curating the packages is done by volunteers who are giving back to a community/ecosystem that they resonate with.
Because the design of nix is so declarative, I think that future tooling could go really far in automating away much of the pain (E.g. minor version bumps, then doing a full build of every affected package and running of tests)
I understand the wish but not how any step towards this would look like that would not automatically be qualified to be in nixpkgs itself.
It seems one can have either of
If there was an approach to get both new and well tested, why should we put that approach on a channel and not directly on nixpkgs (release and master)?
I also don’t see how making more channels than unstable and the stable *-release channels would help anything:
If something gets broken we should fix it on both these channels. How would having a third channel help beyond that?
Futher, my understanding is that changes like the Qt-wrapper changes could not live on some unofficial channel, because they fix fundamental things that e.g. help running Qt apps on non-NixOS. They need to land on the main branches so that peoples’ apps are not broken.
I’m constantly getting broken (and partly very very old) packages
The best ways to counter that are to:
I’ve started a new full thread with a vision on this dedicated to this topic:
I think his/her point was that it should just work without having to put forward a lot of efforts.
I think his/her point was that it should just work without having to put forward a lot of efforts.
And nh2’s point is that there is no «just works» and these efforts still end up being needed… I guess an implicit point is that the discussion will always end up framed as «how we help contributors to get more things done with less effort» and not «how we provide things for ‘invisible’ users allowing them to stay invisible and content», so becoming a maintainer of something makes one heard more.
There are many packages in nixpkgs that are very domain-specific. E.g., I was happily surprised to see two days ago that the sentencepiece library is already packaged. But given the modest size of the Nix community, the small subset that is interested in natural language processing, and the subset of NLP folks that would use sentence piece tokenization, I wouldn’t be surprised if there are at most a dozen users besides the maintainer. One can get far with automated version bumps and tests. But with this kind of package, you have to expect to maintain it if the maintainer loses interest and the automation fails.
So, besides automation, I think it is also important to focus on how we can help/encourage newcomers to start submitting patches and/or become maintainers. Nix is also a community, not (just) a product that one can expect to always work.
I would love to become a maintainer and contribute to the community but would surely need some guidance if not handholding…
Maybe there could be some kind of step by step (video) handbook on the wiki?
Most of the time I can find some info on YT video’s but perhaps that info should be more prominent available right here on the NixOs domain.
Edit: I stand corrected >> Update a package - NixOS Wiki
But then again I had to search for it. Perhaps we should provide a big green button “we need you to become a packager!!”
This discussion is somewhat related:
https://discourse.nixos.org/t/we-need-more-defined-guidelines-for-package-inclusion/
Removing inactive maintainers from the list may make it easier to identify unmaintained packages.
Hydra used to send an email to maintainers when one of the packages they maintain breaks. Unfortunately, this is not the case anymore. A consequence is that since I am on NixOS stable, it is quite likely to not even notice that a package I maintain is broken on nixos-unstable. This makes it harder to be a “good” maintainer and keeping high quality packages.
And contrary to solutions involving more and more tooling, I expect that re-enabling this functionality is easy — nothing to code, only a slight change in Hydra’s configuration.