BTW, from user experience, this won't be too efficient. What do you think e.g. about providing channels with (sqlite) DB containing index for such searches? (I mean using these indices for -i/-q without -A, too.)

... also, search/installation by executable name might also be nice, for which we already do have the command-not-found DB.

@vcunat, it works in 2 seconds for me. Which is not bad at all. I'm not sure sqlite db would be useful or not, but at least that would not work for nix-env -f.

Can you point me to the implementation of command-not-found DB? So I can take a look. But It is separate pull request anyway.

Well, on cold cache just reading the whole nixpkgs tree takes much longer, at least with my slow 5400-rpm notebook HDD (and maybe slightly fragmented tree). But I guess it might not be currently efficient to spend time on such enhancements.

I only remember that command-not-found uses an sqlite DB distributed with the channel. I've never seen the implementation.

I guess this is to some extent obsoleted by the existence of the nox tool which provides a much better UX for searching in general?

@lheckemann, well, I'd better prefer this solution, because:

1. nox "python amqp", shows me nothing, while nix-env -qaP | grep python | grep amqp | wc -l yields 16 (which means nix-env --search python amqp would work too)
2. nox is 3x slower when there is no cache (and I use it so rarely that there is always no cache)
3. nox python | grep amqp yields some garbage. I.e. nox can be used only interactively.
4. And it's yet another tool comparing to just 50 lines of code that does job well

So while was lazy to update this patch it's still good to have. And I would stop using nox if this patch is applied (because I don't feel comfortable with interactivity of nox). On the other hand, nobody was interested in this for two years....

Side-note: there's also this newly-developed nix command. (In any case, I do not have push access here.)

We have nix search now, so I guess there's no point in this one?

Indeed.