Hey everyone! I’m excited to introduce Nixhub.io
Nixhub is a new search engine that let’s you search historical versions of packages from the Nix Packages collection. We’ve built an index of over 400,000 package versions from the Nixpkgs repository, with the goal of making it easy to find and install the specific version you need for your project.
We have a lot of improvements planned, but wanted to get your feedback on our first version.
This does not seem to differ from the already available tool by Marcelo Lazaroni in function. Marcelo’s site has currently has the advantage that its data extends further into the past and can offer a more comprehensive overview.
Nixhub.io seems to be more updated than that tool. For example, the most recent version of rustc on Nixhub is 1.70.0, what is currently available in Nixpkgs, but the other page only lists up to 1.67.1.
Even nixos.org can display the current version of provided packages…
The tool you linked is missing the last few packages, not just the newest. Most packages say the latest version’s date was 3/11/2023. It doesn’t appear to have updated since then.
Nice tool. This is one area where the monorepo causes pain that would otherwise be totally avoidable. If each package had it’s own repo we could just trivially reference git tags on each repo for past versions. Just 2 cents.
I don’t think that would work in practice, as an old app (repo 1) generally need old deps too (repo N, repo N+1 …).
I get what you are saying, but the whole architecture would be different to accomodate that, obviously. In any case, I’m not saying we should change it, just nice to remain cognizant of the trade-offs involved and recognize when a tool exists merely to patch a architectural issue.
That is one thing I really like about Flakes, you get versioning and releases on a per-package level via Git references. The tradeoff seems to be on the discoverability side.
So, if we actually start with stuff like git tags for each package version in each repository, how do we ensure that downstream flakes keep up with upstream changes (e.g. how do we make sure that every flake is built against the latest openssl after a patch for a vulnerability was publicized)?
Right now, this is the job of us, the nixpkgs maintainers, the only thing a user has to do is to make sure that their channels are kept up-to-date.
But in such a setup, an end-user has to make sure that every flake they pull in is actually up-to-date. This is… what nixpkgs currently does for you (i.e. keeping your packages up to date). In other words, we’d stop being a software distribution and the work that’s done in nixpkgs itself (providing a stable package-set that works including selecting versions that work together, applying security fixes etc) is effectively pushed to the end-user.
Also, if you try to do treewide changes then (e.g. fixing up stuff after pushing a glibc update - been there, done that), you’ll have to touch numerous repositories and I doubt that this will be a nice job (I had to touch multi-repo projects in the past and it wasn’t a pleasure).
And yes, it’s questionable if everything in nixpkgs is supposed to be there, some of the software may be better kept in a flake, I know that. But while this is OK, I highly doubt that we should do this for - well - the entire package-set.
Great, thanks
As a feedback:
For my use case, be able to discover older packages is more important, because I have to compile to CentOS 06 or 07, then finding old glibc, openssl, apacheHttp.dev … last week I was using tag 0.14 of 2012 for that 
Why can’t I found scipy there? Nixhub.io | A Nix Packages Registry
Interesting,
nix 2.13.4, right?nice to have [both] options 
Our search isn’t very good with fuzzy queries yet (something we’re working on currently), so you’ll need to include the prefix of the package. Here’s a link to the Scipy results:
for the beginning it don’t need to be fuzzy but vanilla regex?
Yeah that is a good suggestion as well. We also have WIP to search by attribute path and subpath, which should help with the scipy example above
Offering such a site without giant warning box in vibrant colors is extremely dangerous and irresponsible. Promoting people to use outdated, insecure and/or broken software without proper education is extremely worrying.
I couldn’t find anything like that on the site without searching for it or that the nixpkgs version is frozen in time and it is impossible to provide fixes for anything or that the maintainers of those packages are not responsible for the offered state of the package. This is just irresponsible and luring people into doing the wrong decision without properly educating them on the risks they are taking.
Thanks for the feedback @Sandro. We’re working on adding badges to make it obvious whether a package is in the latest release or unstable branch.
Nice! I think I’ll start using this instead of nix-versions, mostly due to the more memorable domain name 
I do really wish there was a way to make such an index available as a flake. So that people can nix run github:jetpack/nixhub#python-1.2.3 without looking up nixpkgs revisions in a browser.
And not just Nixhub! It also gets data from:
I’m hoping it’ll be the one-stop-shop for package versions