I’m relatively new to NixOS(installed at 25.11), and during the brief time I used it, I came across nix-search/nix search for searching nixpkgs for certain packages, which seemed kinda slow to me, it seemed to me like they fetched from the internet each time I queried, which prompted me to create this tool which localizes the whole of nixpkgs-stable (or unstable too, if you so choose) leading to near-instant search results for queries.
It also adds more granularity to searches, like filtering by package/attribute set, exact matching, which I don’t think is in nix search because I did not look hard enough.
Also, as I was writing .nix files, like flake.nix and the like, I couldn’t really get information on the packages I was using, or even like know if a certain package belongs to a specific package set from my lsp (I am using nil), and since I had the nixpkgs data locally, I could just plug into that, and provide completion and hover support for some zones in nix files, where packages are used (this is quite crudely implemented tho). I got it working, and I would like to share my work, hopefully it might trigger some interest in some of you, maybe you can test it out. This is also my first time here too .
I think that would make for some good motivation for this project
I’m a bit confused about the second paragraph, if something is in the config, shouldn’t you query it from there?, as opposed to the copy of nixpkgs
(Since you can create new packages locally, or override the ones from nixpkgs, these might be different!)
I think my tool is quite different from nix-index-database, which is an unstable version of nix-index. Based on what i understand of nix-index, it is a file-search tool, mapping files to packages that contain them. Nidx, on the other hand, just focuses on package definitions and their attributes and versions, and descriptions, basically just what search.nixos.org does but locally.
This is something not implemented yet, I’m only currently using a static snapshot of nixpkgs, so new packages local to the current configuration being worked on are not yet supported. I was planning on adding support for that, like overlays and overrides, as I learn more about them. I just used nixpkgs because I mostly use packages in nixpkgs in my configs, so I basically don’t know much about this, but I’ll try to implement that.
I’m not sure, but I think rather it is nix-index run in a CI for unstable, so you don’t have to generate the database locally.
(Maybe what you meant, but wasn’t sure)
I was mostly saying this because it seems like your tool is trying to do two different things:
Getting information about nixpkgs (typically ones outside your config you would like to add), the principal use(?) of https://search.nixos.org/ or even things like the wiki
Getting information on your current system (what an LSP needs), where do values come from, etc
And I have a feeling (but can be wrong!) that as your project progresses, these two goals will diverge more and more
(=> more needed features, more things to balance in the presence of tradeoffs, etc)
nix-index itself seems like it would be a useful building-block for you ?
Since afaik it gives detailed information about the current state of the system
This isn’t quite true, if I understand correctly: search.nixos.org does use meta data for packages, but also supplements that with data from nix-index where possible. For instance, for the git package, search.nixos.org lists several different binaries under Programs provided, even though Nix evaluation for the package only yields meta.mainProgram = "git". In contrast, for packages that aren’t built by Hydra, search.nixos.org is forced to resort to only looking at meta.mainProgram; for instance, the kiro-cli package only shows kiro-cli under Programs provided, despite the fact that it also contains bin/kiro-cli-chat and bin/kiro-cli-term.
Thanks for this as it gives me clarity on what this tool actually is/what its supposed to be(or intended to be as I was creating it). I am sticking to the first thing you mentioned:
This. The goal of this tool was first to eliminate the need for me to keep opening a tab for search.nixos, just to search for a package, when I could do it really fast on my machine. Also, I think nixd - the lsp (not nidx) does exactly what I do on the lsp side, I haven’t really used it, but I would assume my tool, even though quite constrained, is faster for completion and hover as it is not really evaluating the whole file, rather just interested in specific zones in the file, where packages from nixpkgs are defined.
Basically, it brings search.nixos.org to the editor and CLI but with speed.
I did not know that, thank you for this information. So basically, since I index https://search.nixos.org and it uses nix-index data where possible, my tool is similar to nix-index, ig? ok
.