Pull Request etiquette when submitting lots of packages at once

Help
1

I’m working on packaging the OpenStack CLI in nixpkgs, but it requires adding in dozens of dependencies that aren’t there yet. At least one of them is circular.

Should I make one big PR or one per package in this case?

2

I suggest you first open an issue on the tracker also linking what you want to include and how. In the past we’ve removed parts of openstack because of the maintenance burden. I don’t know how it is with the CLI you speak of, but e.g. the keystoneclient is I think best kept out of Nixpkgs python-keystoneclient: Init at 4.1.0 (+ all openstack dependencies) by SCOTT-HAMILTON · Pull Request #96624 · NixOS/nixpkgs · GitHub.

3

Noted. My goal was to start with python-openstackclient(which depends on keystoneclient and others), and start moving services into NixOS over time.

I don’t mind taking on the maintenance burden, since I know my way around the OpenStack ecosystem fairly well, but I see there is more communication necessary, and more questions to be answered.

In general, though (for those who find this topic in a search), is there a “one PR per package” rule? I usually find reviewing lots of little changes more annoying than one big one, but I’m wondering if it has implications w.r.t. automation or whatever.

1 Like
4

There is no rule against that. I think it is a matter of how strongly packages are coupled. In some cases, it does not make sense to upgrade packages separately (e.g. the AMD ROCm packages pretty much need to be updated together or a major new spaCy version required new model packages).

However, if packages can be upgraded separately, it makes more sense to make separate PRs. That reduces the reviewing load per PR and distributes naturally across reviewers.

2 Likes
5

If this is your first time adding packages to nixpkgs, I would recommend doing one-package-per-PR just so that reviewing the PRs isn’t super taxing on both you or the reviewers.

Also, if you’re just trying to package an application, then the maintenance burden is a bit better than trying to maintain a package. You can look at nixpkgs/python-packages.nix at 74c2ed9e35243b18d70b4a4e91094971e2b59541 · NixOS/nixpkgs · GitHub where I create a python package set overlay specific to the application. That way even if the base python packages diverge from what the application expects, the application can still build and run.

EDIT:
Also, I have some videos:

4 Likes