I can put pkgs.qt6.full in my configuration.nix and get no errors on nixos-rebuild switch, but if I go to search on nixos.org there are no results. How can both of these things be true? I thought maybe qt6.full is something inside the qt6 package, but search can’t find a plain “qt6” package either! I’ve never run into this with any other distro package manager (then again no other distro tells me to go use a web interface to search either).
Because search doesn’t include aliases nor all package sets. Just don’t trust the search to be comprehensive.
2 Likes
Relevant upstream issue: Treat alias names like description · Issue #345 · NixOS/nixos-search · GitHub
It’s unfortunately one of the many ecosystem issues tied up in the flake mess.
I mean, it’s just how most people prefer to do this. There are other options.
For options, you can use man configuration.nix.
2 Likes
What is reliably in the search? Is it just the names of nix files in the nixpkgs repo or …?
I’m a little skeptical of this being a preference, if you have to use the cli to install the package anyway why wouldn’t you prefer something like apt search <name> like every other distro? I’m a little culture shocked that I’m finding guides telling me how to setup indexing to run on a timer, this has been standard fare on other distros for 20+ years.
Anything that resolves to a derivation that is not a duplicate of something else, and hit with normal evaluation. This excludes aliases and some package sets, most everything else is reliably in the output.
If it helps, personally I only hit this with one or two of the things I use, primarily the kernel (which I’ve figured out by now) and emacs packages (which I can reasonably assume are just all available and named correctly, because they’re generated). That’s not to say that this isn’t a papercut that should be solved; there are many of those around.
Personally, on other distros I also rarely use the package search features, albeit a bit more than on NixOS. I’m almost certainly in my browser when I determine that I need something new anyway, so by the time I decide to install something I have already figured out the package name. Between tridactyl and a good tiling WM there is otherwise no practical difference in convenience, and installing new stuff while offline is impossible anyway, so I don’t have a use case where the browser search isn’t an option.
On NixOS I also often read the package definitions, and almost always the module definitions, so the source links on search.nixos.org are incredibly useful, as it keeps me from having to git pull the massive nixpkgs repo for a few mins just to read a single file. I also just install things more rarely because there is never a need to reinstall anything, and all my computers share the same configuration.
Not that I’m knocking your preference, I get preferring CLI search, but the browser search definitely seems to be preferred on average. Occasionally someone like you comes along and is shocked that pure CLI use isn’t everyone’s preference, but I do think you’re in the minority.
This doesn’t mean your preference shouldn’t be supported well, it’s just likely also why it isn’t, because the path most taken gets the most maintenance.
Hm, I’d thought programs.nix-index sets up the search index based on the one generated during the hydra build for programs.command-not-found. I’d suggest helping out here, I’m sure people would love to see this requirement go away, and all the tooling is already in place. Probably just needs some hooking up.
1 Like
No. It lists attributes that aren’t aliases, and package sets that are explicitly marked to recurse into. I don’t rely on the package search generally.
nix-index-database is a pregenerated database. But it only includes things cached by hydra (i.e. free packages). I use it to find names of files in a package but not package names.
FWIW the most reliable way I’ve found is to search the code.
2 Likes
This does often take grokking the code, though, especially for aliases, and ever since the packagesFromDirectoryRecursive change you also need to check the filenames, so you need both find and grep. It’s “reliable” if you already know an attribute should exist.
It really sucks that the answer is always “read the code”, but hey, I think I’m preaching to the choir.
2 Likes
I recommend nps for CLI search.
Found out about it a few weeks ago and it’s been perfect.
2 Likes