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.
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 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.
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.
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
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.