NixOS Package Information Platform

TLDR: Let’s create a NixOS Package Information Platform. A web site where you can check the status of packages and get package specific informations such as a list of commits, stable/unstable repo status, open issues, PRs, links to latest hydra builds and diffs of commits, etc.

Something I often miss with NixOS is some kind of detailed package information platform. Of course I can always go to the Github repo and search for issues, commits, etc. but this is quite ineffecient and intransparent, since Github itself isn’t designed to be a package repo :wink:
There is also the NixOS package search, but at moment it contains no detailed informations at all.
I am more thinking of something similar to sites such as https://packages.debian.org/buster/vim, https://tracker.debian.org/pkg/vim or https://aur.archlinux.org/packages/vim-git/.

There are multiple reason I am sure this would benefit the community:

  1. It happened twice to me that: A PR has been created but kept back for multiple weeks because of the breakage of another package. Somebody else created a commit with exactly the content of the PR and pushes it straight to the master - obviously breaking the other package. I could blame the commiter for not checking for an existing PR, but honestly it is very easy to miss somthing on Github, especially if no Bug report exists. An information system would show PRs and existing Bug reports. No need to use the github search which can hide important information and cause user errors.
  2. It would make the whole NixOS system a bit easier for newcomers, as the initial learning curve gets lower (no need to understand githubs issue system, the Nixpkgs structure, etc. Package informations can be obtained similar to any major distro)
  3. It would create transparency.
    This point is in my opinion the most important one, because transparency normally also leads to security. If I am interested in the vim package, right now it is quite tedious for me if I would want to review new commits without being a maintainer. And it is certainly very hard to promote such a reviewing process. On the other hand with an information platform it would make it easy for me to just check that one page of this package every now and then for new commits (or write a very simple cronjob to inform me of new commits). Even more, we could promote such a reviewing process by e.g. letting logged in users add a :+1: if they have reviewed a commit themselves and display commits with less than X reviews in bold red. And then if such a review process promotion would work well, merging an RFC like a Merge bot for maintainers may be way less concerning than it is now. Even without such a hypotethical review process, being able to reliably show all commits for one package would already be enough for me to like the idea of the merge bot way more.

What do you guys think about something like that?

And I want to be upfront: I am a sysadmin, I have no real programming experience apart from bash/python scripting and can’t really create such a platform by myself (actually I tried to create something with python/django but I’m already overwhelmed with the github api :frowning_face:). So the second and probably way more important question: Are there people who are as interested in such a package information system as I am and would be able to spend some of their time to help creating such a platform?

Thanks a lot for all your opinions and I really hope we can get something rolling! :slight_smile:

12 Likes

This seems like a big problem. It seems to me that nobody should be pushing package changes straight to master, much less doing so without searching open PRs for is:pr is:open in:title packagename first.

3 Likes

Yeah that‘s what I mean. What if there was no PR but a bug report which already indicates that the problem can‘t be solved easily?
I know these are more likely edge cases and an information platform won‘t solve them all either, but it would make getting an overview of the current state of a package certainly more easy for both maintainers and administrators.

Maybe for that particular case of duplicated PRs / package updates, a bot should comment for every new PR if there’s already a package / PR that matches the new package’s name and therefor that need to be considered.

No, the second ones weren‘t PRs, they were commits straight to the master. Also as far as I remember, they were bugfixes rather than updates.

I wonder if it would be complicated to add some functionality to ofBorg so that it would report informations to a platform or if it would be easier to create a second bot.

Hi, I would definitely appreciate if more information about each package could be added to the package search. OTOH, if this was created as a separate platform, this would probably be way less cool simply because people wouldn’t even know about it. If for some practical reasons this must be separate, make sure that at least a link is provided from the package search results to the platform with additional info.

2 Likes