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.