Flag packages out of date

I wanted to ask your opinion about the possibility to “flag” a package on Nixpkgs out of date. At the moment, an issue at GitHub has to be opened, a lot of information has to be filled in, and even the current version number and the desired new version number have to be stated.

From the perspective of a user, this is a lot of unnecessary boilerplate. It would be preferable to have a data base accessible with all available packages (on Nixpkgs master I guess), and a button “flag this package out of date”. Like this, packages cannot be flagged twice. The package maintainer(s) have to check the new version of the package anyways, and correspondingly update the Nix expression.

Cheers!

3 Likes

The majority of packages in nixpkgs is unmaintained.

I don’t get the point. If they are not maintained, who updates the packages when they are reported out of date via GitHub Issues? What would be the difference when packages are flagged out of date in some other way?

Usually nobody. Packages are either updated by the nixpkgs-update bot or by random users who notice that they are out of date.

That somebody would have to build and provide the infrastructure.

1 Like

That’s exactly my point, to reduce the burden for those /random users/. I am one of those :).

No doubt, it would require manpower to setup a package database (or connect to the Nixpkgs one) and the corresponding web service.

1 Like

I think keeping track of upgrade requests in a GitHub issue makes sense. Also all the fields in the template (nixpkgs/out_of_date_package_report.md at ddbad297028c65b23490f543e2e3b487a6b9c097 · NixOS/nixpkgs · GitHub) seem reasonable to me.

That’s quite understandable.

I agree it would be neat if we had some page that can collect most of the information asked for in the issue template and pre-filled it. That looks possible, but not trivial :wink: .

That’s exactly the point with the Nix community. There are not enough people. So if you are not doing it yourself, it’s not gonna happen.

5 Likes

Maybe the scope of GitHub - jonringer/basinix: (WIP) Nixpkgs pull request review website could be extended.

Or, if you just want to find outdated packages, you can check Repology:

There is no need to flag anything manually – as soon as some other package database has a newer version, the package is recognized as outdated.

2 Likes

While maybe technically accurate in the sense of listed maintainers (I haven’t done a survey), I think this characterization might be a bit misleading. Many packages have listed maintainers, and I believe we’ve stopped accepting new packages that don’t have a listed maintainers. On top of that, there are many people with commit access that maintain lots of packages without being listed as a maintainer for it. During releases, we do Zero Hydra Failures where the community tries to fix as many packages as they can.

5 Likes

Your bot also does a great job at updating a lot of packages, but the reality is that we have a lot of “drive-by packagers” who see a package that is missing, make a PR to check it in, and then immediately abandon it. That is not really a profound problem, because none of these packages are critical.

3 Likes

Re: opening issues

I encourage to check out the following command in your local shell (provided gh cli installed):

gh issue list --label='9.needs: package (update)'

In a way we accepted for github to be our database backend.

I feel a bit offended by this statement. I’m trying over and over to move things into the right direction with my own time and I have a very poor success record.

As recently as today.

It’s not people. It’s organization.

2 Likes

You are referring to a completely different aspect. The present issue is about external tooling, not about altering the foundations of nixpkgs. The issue you’re trying to solve might be better tackled as an RFC. Trying to “shoot from the hip” with a PR for such things is generally bound to fail (see e.g. USE flags).

1 Like

I still feel offended. Not directly by you, but systemically by how things are.

From the viewpoint of the community as an (hypothetical) independent actor, there is no point in achieving “cheap” consensus about (a general idea of) resource scarcity and at the same time not achieving “effective” consensus about making practical and efficient use of the available ones.

It’s gross.

We can leave it here, since it’s off topic, as you correctly noted.

One of my stretch goals was to have you enter your maintainer name, and it would show you which of “your” packages are now failing, when they began failing, etc. From a UX standpoint, I’m still not certain how this should work, because of how many branches a user may care about (e.g. master, staging, staging-next, release-XXX). Also, people may only be a maintainer on a given branch…

Maybe I could have some repology / github integration which would also determine which are out-of-date as well.

Would be nice to bring more value in declaring yourself as a “maintainer” in nixpkgs.

5 Likes

Thanks for your replies!

  • @blaggacao Thanks for pointing me towards the github client, it seems a rather useful tool!
  • @jtojnar The repology notification tool is definitely a must have for maintainers! I will set this up for the one package I am maintaining at the moment :), there will hopefully be more.
  • And yes, it would also be great to have an “update request review” tool.

Nevertheless, I think the points are all made from the maintainers point of view. For users, maybe a clever GitHub Update Request Issue template would solve the additional boilerplate when reporting outdated packages. In the end, the act of “flagging” a package out of date feels more natural to me though.

1 Like

Personally, I am using nixos-search a lot. The best for me would be a button there (or on an equivalent other site if that matters).

EDIT: Flagging packages on nixos-search would even allow for branch-specific flags (well probably not branch-specific but channel specific).

For packages that have a standard expression format, and the build hasn’t fundamentally changed, they could just update the package doing:

git checkout -b bump-mypkg
nix-shell -p nix-update --run 'nix-update <pkg> --commit'
nix-build -A <pkg> # ensure it builds
git push <fork> bump-mypkg

and then create a PR with the bump. It is more involved, but less involved than finding where the nix expression lives, finding the latest version, update version, calculate new sha, building it, making a commit, then pushing to a fork.

For patch bumps, the above code is probably sufficient. For larger changes, there will some nix knowledge needed.

6 Likes

I agree this would be very useful. I think it would also be useful if you could add packages to this list of “your” packages manually: this way you could track packages that you care about (and might want to help get unstuck) even if you’re not ready to declare yourself maintainer.

(there’s some overlap with ~raboof/nixpkgs-contributor-dashboard - sourcehut git but I’m not actively working on that right now. Added a link to the README)

We could encourage to fork and open issues on that fork for that purpose.
That would fit nicely with gh issue status -R blaggacao/nixpkgs.