Is “nix search” broken?
(I think NixOS urgendly needs QA/QC: things unfortunately constantly break, people intentionally break things (because “they are working on an improvement”), there are lots of broken packages, nobody knows what’s broken and what’s working, and nobody cares. )
$ nix search python3
error: experimental Nix feature 'nix-command' is disabled; use '--extra-experimental-features nix-command' to override
$ nix --extra-experimental-features nix-command search python3
error: experimental Nix feature 'flakes' is disabled; use '--extra-experimental-features flakes' to override
$ nix --extra-experimental-features nix-command --extra-experimental-features flakes search python3
error: cannot find flake 'flake:python3' in the flake registries
How can this be fixed / should I report a bug / how can I search for packages (except on the website)?
It’s true, lots of things are broken, but such is open source volunteer work. Based on my experience with the Nix maintainer meetings twice a week, as well as every other maintainer and contributor I ever talked to, I can vouch that no one is breaking things intentionally, and that people really care about making and keeping things working. Take for instance the care the Nixpkgs Architecure Teams takes to make a seemingly straightforward refactoring of the package repository happen in a way that does not break the codebase or people’s workflows.
It’s just that time is limited, even for those few who do get paid, and the project is growing ever larger. Everyone has to prioritise what to work on, and that’s not always communicated well – or, unfortunately often enough, at all. And of course, people make mistakes.
You’re warmly invited to get involved in fixing what’s broken, especially since you appear to care a lot (which I greatly appreciate ). Feel free to get in touch with any of the community teams to find out what they’re up to and how you can help.
Unfortunately, nix search only works properly with flakes, as of nix 2.4. The new flakes-based command replaced the old one, and the old functionality isn’t accessible anymore through it.
Assuming you don’t care too much exactly which commit of nixpkgs is involved, you can do this:
Which will search the nixpkgs in the flake registry, rather than your <nixpkgs> channel. Presumably you have to specify what flake to search in an effort to make nix less nixpkgs-centric, but I can’t say I think that was a good choice, really.
Why this doesn’t work, however, I don’t honestly know. It seems like it should:
$ nix search -f '<nixpkgs>' pkgs python3
error: Please be informed that this pseudo-package is not the only part of
Nixpkgs that fails to evaluate. You should not evaluate entire Nixpkgs
without some special measures to handle failing packages, like those taken
by Hydra.
Thanks.
(It’s sad that the ui got worse again – "nix search " was a nice improvement compared with “nix-env -q…”; the “flake” should at least be optional and search all channels/flakes without…)
Then I’ll probably only report a bug for nix-generate-config.
(Since it generates a config which says:
# List packages installed in system profile. To search, run:
# $ nix search wget
search.nixos.org is great; but it cannot completely replace an offline/local search.
No, open source volunteer work does not lead to broken things. I’m not complaining about the work of the volunteers – I’m complaining about missing structures and rules which
(a) make sure that things do not break unnecessarily,
(b) automatically test if packages are broken and
(c) document (machine-readable) what is broken and what works.
Unfortunately, things are broken intentionally – e.g. search.nixos.org was broken for a long time because “someone worked on an improvement, and so first broke the current system”. I’m again not blaming the volunteer, I’m blaming the missing QA and the missing rule “if you improve something, do it separately, test it, and then switch from the old to the new version – and until this don’t break the current version”. (That’s simply the normal way in all productive environments; without this rule, you don’t qualify for productive uses but are more or less a “toy”.)
This “nix search” problem also results from this missing rule/missing QA.
I am planning to get more involved and start some QA- and usability-initatives for NixOS; but unfortunately, I currently don’t have the time.
Yes, I fully agree, and I’m a strong proponent of offline-first.
And in my opinion you’re fully right to do so, and I’m sure many others will agree with you. I’m personally committed to improve the situation and already spend some time on that, but I think it’s tricky in a diverse, globally distributed community with many different voices and interests and, all in all, very limited resources given the size of the project.
For posterity, I’ve figured out how to contort the new nix search into searching channels. Be warned, it’s rediculous:
$ nix search --impure --expr '{ legacyPackages.${builtins.currentSystem} = import <nixpkgs> {};}' '' hello-unfree
* legacyPackages.x86_64-linux.hello-unfree (1.0)
An example package with unfree license (for testing)
It’s utterly silly that it searches -f/--file and --expr sources for flake output structures and also requires you to select an attrpath within them before the actual search terms, but… I guess you could wrap all that away and get something decently functional.
AFAIK “nix search” was first added and promoted as “nix-env”-search replacement (and nix-generate-config still does this).
Later it was defined experimental, changed its syntax and disabled by default.
So, I did not rely on an experimental API – instead the API changed to experimental.
Whatever its official status, the fact is that nixos-generate-config created configs with comments recommending its use for years. It wasn’t experimental in practice.
For anyone interested, I created a simple wrapper script around the ridiculous solution above, which also filters the extraneous flake schema parts from the output:
)
). Feel free to get in touch with any of the 