Nixpkgs-update/r-ryantm logs


I manually run it every couple weeks or so. I’d like to automate it but I’m a little scared to spam everyone with low quality PRs.

I expect this to work because it uses the name of the package from the nixpkgs JSON dump returned by the repology API.


I think it would be great if it could be run daily or even hourly - there’s no reason why humans should do the trivial work :).

Have you seen many low-quality PRs produced by it? And what consitutes a low-quality PR in this case?


It takes it 2 to 3 days to get through all the packages as is. This could be sped up drastically by maintaining a database of failed outPaths.

I’m just worried that the bot might not have enough checks in place that it submits some nonsense PRs. I think there is some aspect that nixpkgs-update is introducing extra work for maintainers, because it is catching all the updates from hyper-actively updated packages, and I want to keep the overall quality of nixpkgs-update PRs very high so they are easy to merge and to trust that they will be good.

Another reason I like to manually monitor it is that I am usually developing nixpkgs-update and I don’t have much of a test-suite, so if something goes wrong, I like to catch it through manual monitoring. If I work on improving the test suite, I think I’ll feel much more comfortable making it automatically run continuously.

1 Like

Thanks, all of that sounds very reasonable.

I wonder if it could automatically close (or if not privileged enough, label as stale somehow) PRs that are superseded by a newer one. I understand that this would be adding a lot of responsibility and logic into it though.

But I think that this 's an extremely valuable tool that is showing the way we need to go to make nixpkgs scale better.


2019-05-11 log