Hi, as part of helping a client upstream suitable parts of their nixpkgs overlay, I’m adding some new packages to nixpkgs.
Some of these packages are libraries that (as of now) have no users/dependents inside nixpkgs, but are being used within the client’s (proprietary) code base. (For the record, I’m adding myself as a maintainer to all the new packages I’m adding, and I’m happy to remain their maintainer for the foreseeable future.)
That’s my interpretation. The intent of that line in the context of its PR is to keep Nixpkgs free of libraries that become insecure due to a lack of attention. It’s only a ‘should’; perhaps if you can make a strong case that your client will maintain this library diligently despite no in-tree dependencies forcing the issue, I’d let it slide. But otherwise, I think that one client having a proprietary application that uses this library is a pretty central example of ‘niche’. If they go poof or just stop using this dependency, who’d know? How would any issues get caught? At least with an obscure OSS leaf application, someone else could come around and pick it up if the original maintainer loses interest.
I definitely question the inclusion, I also question the wisdom for your client: surely it’s better for them to maintain control of it by keeping it in their own tree / overlay? I get that these libs are relatively unmaintained but if new versions / patches are produced on whose schedule do they want to take those patches?
Also if they cease to be your client do you intend to keep maintaining it for free forever? Why should the nixpkgs cache bandwidth / ci minutes be spent on this?
Hi! I’m the one that originally suggested that line. My intent was any dependents, not just those in nixpkgs. It was meant to be an easy answer for libraries to satisfy the “How realistic is it that it will be used by other people?” criterion: if the library is being used, then the answer is definitely yes. If it isn’t, then the answer is almost certainly no.
However, if you don’t have any dependents inside nixpkgs, you should write a basic program with basic functionality as a test, so you can catch any breakages. This isn’t a requirement, nor is it documented anywhere, but it is best practice.
Thank you for your feedback! I certainly agree we don’t want unused or broken libraries in nixpkgs.
For the libraries I’m adding, I make sure they come with tests that exercise the library’s functionality, and that these tests are run in the checkPhase. This does not technically count as a separate dependent in nixpkgs, I guess, but I hope it still follows the best practice.
Update: the PR is now merged, so the answer to the original question is now a definitive yes, as long as the guidelines are followed (in this case specifically, an example program should be added to passthru.tests)
Another 2c: if in doubt, just write it down in the PR who do you see potentially as potential users, to what uses, why they’d chose that over this. FWIW even in general, would be nice for meta.descriptions and services.*.enable options to explicitly answer these questions[1].
For cnpy and cnpypp specifically, I’m pretty sure I at some considered them for my stack at the uni, probably had Nix expressions too. I’ll probably need them again some time for obvious reasons. That there are no revdeps in Nixpkgs yet is (trivial) is a marker for “pay attention”, as are CoIs and commercial relationships, but they’re not more than that. Judge. Make your case if judged. Smth