nix search: Disallow empty regex

[iFreilicht]

Motivation

This will make invocations of nix search without a regex fail with the following error message:

nix search .
error: Must provide at least one regex! To match all packages, use '^'.
Try '/Users/feuh/repos/nix/outputs/out/bin/nix --help' for more information.

This protects users from accidentally printing every package in nixpkgs. If someone still wanted to do that, they can by explicitly passing ^. Why we recommend this over ^ is explained in the docs.

Context

Fixes #4739.

Also fixes #3553 in spirit IMO. That issue calls for outputting the entire output of nix search --help when no regex is passed, but that would be a more substantial change, as all new CLI commands have no short help and --help opens the manpage. If we wanted to change that, we should change it for all UsageError invocations.

I considered adding an --all flag, but this seemed redundant. I briefly looked into other ways of enforcing at least one argument with expectArgs, but adding optional = false didn't change the rest of the implementation or the docs, so I opted not to touch that part.

Priorities

Add 👍 to pull requests you find important.

[fricklerhandwerk]

This is a strict improvement in my opinion.

outputting the entire output of nix search --help when no regex is passed, but that would be a more substantial change

That would be a really cool change though.

[roberth]

Took a while for me to realize that ^ for outputs and ^ in a regex are very different things.
I guess it could confuse others to see a lone ^ in a place where you often find installables.
Maybe I'm overthinking this.

[iFreilicht]

@roberth Good point! I added a note about this to the description.

Also added release notes, this is ready to merge from my side.

[tomberek]

I'm coming back to this and the error message is still confusing. I can imagine a user then trying "nix search ^". The key piece of info is that nixpkgs is not the default flake(ahem: dram), and that they need to specify it, assuming that is the most commonly searched flake. That there needs to be more positional arguments.

[iFreilicht]

That's a good point. Ideally, the message would look like this:

$ nix search .
error: Must provide at least one regex! To match all packages, use 'nix search . ^'.
Try '/Users/feuh/repos/nix/outputs/out/bin/nix --help' for more information.

But this also has to work for all other kinds of installables (like file and expr), and after trying for over an hour now, I just can't make it happen. The easiest way is to use installable->what(), but that makes the message very confusing again:

$ nix search .
error: Must provide at least one regex! To match all packages, use 'nix search git+file:///Users/feuh/repos/nix#packages.aarch64-darwin ^'.

Or for files:

$ nix search -f tests/functional/search.nix 'foo'
error: Must provide at least one regex! To match all packages, use 'nix search foo ^'.

I would need some function that returns the installable verbatim, or at least close to verbatim. That would be useful for other error messages as well. Maybe I'll have another crack later.

[iFreilicht]

@tomberek I now settled on this:

$ nix search .
error: Must provide at least one regex! To match all packages, use 'nix search <installable> ^'.

I don't know if it's a strict improvement over just ^, as <installable> introduces potential confusion again.

Please tell me which variant you like better, and then let's get that merged. Making a function to get the installable verbatim proved to be even more difficult than I thought, and I don't want to block a simple UX improvement like this on a big, possibly controversial addition.

[tomberek]

I do like the updated message, thx.

[edolstra]

Not really in favor of this. nix search nixpkgs seems to me like a perfectly logical and convenient way to show the contents of Nixpkgs (though it should be piped into the pager). Why make the user add unnecessary arguments?

[iFreilicht]

I guess I should've seen that coming after #4809 was declined.

I disagree with "perfectly logical". I would expect a command like nix list or nix show to show a list of the contents of something. "convenient", sure. Once you know it, and as long as you use nix often enough to remember it.

I would appreciate concerns like this being raised before a contribution is merged, but whatever.
It would also help if issues that are not supposed to be fixed were just closed instead of leaving them open forever so I don't spend my limited time on stuff that is not gonna get merged anyway.

[tomberek]

My rationale: It is a common problem for an initial user that they will often type "nix search python" and become bewildered. This helps address that by teaching them what they messed up. I agree it is convenient to automatically scan for everything, but the cost of confusion for beginners is too high for the slight benefit.

[iFreilicht]

I mean I concede it's not a perfect fix. Right now:

$ nix search python
error: cannot find flake 'flake:python' in the flake registries

With this PR:

$ nix search python
error: Must provide at least one regex! To match all packages, use 'nix search <installable> ^'.

I would like it to look more like this

$ nix search python
error: Must provide at least one regex!
       To match all packages in the flake 'flake:python', use 'nix search python ^'.
       To search for 'python' in the 'nixpkgs' flake, use 'nix search nixpkgs python'.

But right now, it's seemingly impossible to get the initial arguments that were passed to a command inside InstallableValueCommand or any similar class like that, and my attempts at implementing this seemed to yield very ugly solutions.

[daniels]

So, I just noticed this now, after happily searching with no regex for a long time. Not all flakes are nixpkgs, so a full listing is not that uncommon, and for #attribute-search it is even more useful to do an empty search.

This "fix" is really an ergonomic regression. At least on my keyboard. ^ requires a modifier to type and is also a dead key, meaning I have to type <space> <shift>-] <enter> <enter> instead of just <enter> after nix search nixpkgs. I don't know which newcomer would prefer that.

[iFreilicht]

Not all flakes are nixpkgs, so a full listing is not that uncommon

Ah yes, we talked about that, but concluded that most invocations of nix search are with nixpkgs, so we optimize for the majority case here. There was also a discussion in the Nix Team that yielded an interesting point, namely that if Ctrl+C worked better, #4739 would not be an issue.

and for #attribute-search it is even more useful to do an empty search.

Do you have an example for what the usecase of this is? I tried it on a few of my flakes and it seems to be either useless as it only outputs a single line or errors because it tries to evaluate things that aren't derivations.

This "fix" is really an ergonomic regression. At least on my keyboard. ^ requires a modifier to type and is also a dead key, meaning I have to type -] instead of just after nix search nixpkgs. I don't know which newcomer would prefer that.

This is a very unique situation, and we just can't consider everyone's custom setup. On most keyboards, ^ is a simple two-key combination, either with Shift or Alt Gr. I'm in a similar boat myself as I use a custom keyboard with the US-Intl layout to be able to type german characters easily, and I just added a macro so Shift+6 actually types Shift+6, then space.

I think I tried to allow an explicit empty string "" as well, but AFAIR this was not as trivial as expected and so I left it out.

[daniels]

Not all flakes are nixpkgs, so a full listing is not that uncommon

Ah yes, we talked about that, but concluded that most invocations of nix search are with nixpkgs, so we optimize for the majority case here. There was also a discussion in the Nix Team that yielded an interesting point, namely that if Ctrl+C worked better, #4739 would not be an issue.

Yes I saw that and agreed.

and for #attribute-search it is even more useful to do an empty search.

Do you have an example for what the usecase of this is? I tried it on a few of my flakes and it seems to be either useless as it only outputs a single line or errors because it tries to evaluate things that aren't derivations.

I use this to explore package groups, like what vim plugins are available, what Ruby gems are packaged for nix etc. When typing nix search nixpkgs#rubyPackages in my understanding I have already provided a search term, the extra required ^ is just extra typing and mental burden.

This "fix" is really an ergonomic regression. At least on my keyboard. ^ requires a modifier to type and is also a dead key, meaning I have to type -] instead of just after nix search nixpkgs. I don't know which newcomer would prefer that.

This is a very unique situation, and we just can't consider everyone's custom setup. On most keyboards, ^ is a simple two-key combination, either with Shift or Alt Gr. I'm in a similar boat myself as I use a custom keyboard with the US-Intl layout to be able to type german characters easily, and I just added a macro so Shift+6 actually types Shift+6, then space.

I don't think it's very unique at all. The location might differ (my example above is from a Swedish standard layout, though I used the ] to signal the location of the key where it would be on an English layout, the actual Swedish key used is ¨ unshifted) , but having ^ as a dead key is common across many layouts. It is used for accenting other characters after all. And that is the primary problem, even though adding the required argument at all is also a usability regression to me.

I think I tried to allow an explicit empty string "" as well, but AFAIR this was not as trivial as expected and so I left it out.

Yeah, my workaround that I have yet to internalize is to search for ., with a lot of green in the output ...

[daniels]

Oh, and I also use attribute search to check the version of a package.