Hi.
Introduction
nixpkgs-update is the code used by @r-ryantm to semi-automatically update nixpkgs. I use data from Repology.org to generate a list of outdated packages. A package is considered “outdated” if a newer version of the package is available at any other repository tracked by Repology. nixpkgs-update tries to update each package in the dumbest way that could work. It find-replaces the old version number with the new one, uses nix-prefetch-url to try to get the new hash, then tries to build the package. If it succeeds, it runs some checks and makes a pull request. It also uploads the built package to Cachix, which people can use to manually test the package without building it themselves.
nixpkgs-update updates
Since I made nixpkgs-update earlier this year, I’ve been adding various improvements to it. In celebration of NixCon 2018, I pushed hard to get some new features out the door:
-
Rebuild reports. The PRs made by nixpkgs-update now say what packages need to be rebuilt if the pull request is merged. This uses the same mechanism OfBorg uses to put rebuild labels on PRs. Not limited by labels, it can tell the exact number of rebuilds and list some of the attrpaths that would need to be rebuilt.
-
PRs against staging. This is a feature I wanted on day one, but was tricky to do until I had the rebuild information. When someone submits a PR to nixpkgs that needs to rebuild a lot of packages, we typically request that the target merge branch be
staging. This lets us save computing resources by combining a bunch of mass rebuilds. (If two mass rebuilds need to rebuild the same package, the package only has to be built once.) For a long time, people have been manually moving @r-ryantm’s PRs to staging if needed, and this wasn’t super annoying to do because its commits always have the parent ofgit merge-base master staging. But now it will automatically make the PR against staging if 100 or more packages need to be rebuilt by the change. -
Logs. This feature has been around for a bit, but I want to sneak it in here to help publicize it. I make the logs from r-ryantm’s runs available online. There are a lot of packages
nixpkgs-updatecurrently has no hope of updating. Please dredge the logs to find out why your pet package is not receiving updates. -
Better Cachix instructions. When I originally introduced Cachix to nixpkgs-update, the instructions were buggy and onerous to follow. With a lot of help from others, they are now awesome! With one command, you can add the built package to your store without installing Cachix and without trusting r-ryantm for all your caching. Now you are one command and only seconds away from trying the latest version of a package on your computer.
-
Updating Python packages. When nixpkgs-update started, it tried to update everything and this quickly ran into problems with updating the special package modules like Python, Go, Ruby, etc., and we decided the best approach would be to skip these packages until the bot could be made smarter. Recently, @FRidh gave his blessing to start updating the Python modules if they cause fewer than 10 rebuilds. This inspired the Rebuild report above, and I’m happy to say r-ryantm is now trying to help out with updating the Python package set!
That’s all nixpkgs-update updates. Thank you for letting me make so many pull requests against nixpkgs over the year, and thank you for merging so many of them! Now for some fun.
r-ryantm’s GitHub profile:
nixpkgs reports to Repology almost having as many packages as the Arch User Repository (AUR), and many more are up to date:
When NixOS 18.09 was released a lot more packages were up to date:
Thank you and happy NixCon 2018!
RyanTM
