Can I add libraries with no dependents _inside_ nixpkgs?

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.)

Examples:

However, I’ve since discovered this recent addition to the documentation, specifically this sentence:

Library packages should have at least one dependent.

It is not clear to me whether this refers to dependents inside nixpkgs, or if dependents in downstream forks/overlays are sufficient?

1 Like

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.

2 Likes

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?