awesome website.
I wonder if you envisioned searching a version of package that satisfies constraints on its buildInputs ?
Right now I am trying to create a python environment with spacy and tensorflow but they use different versions of protobuf, with spacy depending on a neweer protobuf. which creates a collision. A tool that could list nixpkgs versions of spacy that depends upon the older protobuf version X would be helpful in this situation .
I recently noticed that this site does not seem to take the status of cache.nixos.org into account. It sometimes returns a nixpkgs commit and the requested package needs to be built from source even though for another nixpkgs commit, the same version would be available in the public cache.
Is this kind of cache-awareness planned in the future?
While its definitely beyond this little CLI tool, I have spent and enormous amount of time considering and working on that problem. I think solving that problem is a must but the current structure of nixpkgs is not capable of handling it. Basically I would need to build a massive database index of all nix packages (which is what nixhub and those other websites have done for me up until this point, and even those have problems) on top of having some way to scan the dependencies of your project without building your project. Ex: have every individual python package as an input to a nix flake. Stuff like the flattening of nixpkgs helps a lot and is a movement in the right direction, but we are a long way off from automatic shared - dependency resolution. The real problem is data. A question like “show me all versions of python” is already so hard that nixhub (which has done tons of scraping and processing work) doesnt even fully answer that question. We would need to answer the even harder question of “show all versions of python, who’s recursive dependencies include X version(s) of Y package” – without building them or the even harder question of “given A B C packages need X Y Z, find versions of X Y Z that satisfy the needs of A B and C”. That question is probably not going to be (properly) answered with a tool for years.
Yep, I would like to fix that, and its somewhat realistic to fix (PR’s are accepted BTW if you ever feel adventurous).
I’d also like to prioritize tagged commits, e.g. show 25.05 and 24.11 above the other random commit versions.
Once I get those down I’ll probably do a 1.0 release announcement