Adding package to nixpkgs that requires about 15 new packages

I have a python package that I am adding to the nixpkgs store. The main motivation is that I am trying to make sure that nixpkgs has the top 360 most downloaded python packages

The package is oslo.config oslo.config — oslo.config 8.8.0.dev6 documentation and is has a TON of dependencies. Basically needs 50% of the openstack python packages of which nixpkgs has none so far.

  • Should I included everything in one pull request with 15 commits?
  • Or is it better practice to do it in batches?

I should mention that I have already added 20 or so packages to nixpkgs so I am relatively experienced and I have made sure that all tests are run and well written with best practices. Is there anything that I can do to make the code reviewers job easier?

As you said, you’re experienced with nixpgks. You probably know how to make good commits.

I would expect to see one PR, instead of having mutliple PRs depending on other PRs. Easier to review the intended end-result than having to somehow piece together the PRs and verify them in isolation. At least, that’s how I’d implement it.

1 Like

Thank you. I just wanted to make sure I was doing it the best way. Because I know on the code review side it will be a lot to check.

1 Like

When updating N packages, I’ve often seen a single PR with N commits, each of which says

  • foopkg: init at X,
  • barpkg: init at Y
  • bazpkg: 1.0 → 2.0

I wouldn’t have multiple PRs open that depend on a merging order between them, but that said, if you have one commit ready to go that packages foopkg and you’re still working on the rest, it doesn’t hurt too much to send a PR for just that package and get it reviewed + merged while you continue working locally on the remainder.

I might do something similar myself, since I’d like to get the pypi package localstack and localstack-client (a cloud testing and mocking tool for AWS), which is currently ~2000th in popularity and has a large dependency closure:


I really appreciate you sharing that link to the top pypi packages. I didn’t know it existed.

Some time ago we threw out all the Openstack related Python packages because they weren’t maintained and they were a pain to maintain as well.

A few times some people wanted to add these packages to Nixpkgs again. I recommended then, and also now, to use an overlay for it, because we don’t have the capacity to maintain this in Nixpkgs.

1 Like

I want to add that the more packages we add in Nixpkgs, the harder it gets to form a working package set. It’s already extremely hard to keep the most recent version of everything without breaking other packages.

Also, in case of pure Python packages pypi2nix may be a good solution. I think it will work quite well for openstack.

Thank you. Extremely relevant and I wish that I had spotted that pull request earlier. They are a pain to develop since they tend to pin the packages so often to old versions.