Search Command Improvements

[theduke]

• adds a --skip-description flag for not searching in package descriptions
• adds a --plain flag for plain output that only prints a line with the package path for each match

[edolstra]

I'm not sure --plain is all that useful since you can do the same thing using --json, e.g.

# nix search --json | jq -r 'keys[]'

What's the intended use case for --plain?

The name --skip-description is a bit ambiguous since it's not clear whether it skips searching or printing the description.

[theduke]

The name --skip-description is a bit ambiguous since it's not clear whether it skips searching or printing the description.

Yeah, I wasn't sure about the name. I started with --name-only / -n, but it's rare to not want to search in the path as well, imo.
So I'm happy for other suggestions.

I'm not sure --plain is all that useful

This is a very common need for me.
I often want to either quickly narrow down available pacakges, or just find the name of one I forgot, and the default output is too verbose for that.
It's also useful for piping the results into some other tool or writing it to a file.

Remembering the json structure each time and adding the |jq pipe ends up as a pretty annoying extra step.
A shell alias could of course fix that for me, but only on personal systems, not on servers.

I think it's useful enough to include.

[stale]

I marked this as stale due to inactivity. → More info

[abathur]

Some potential flag names:

• --exclude-description or --ignore-description
• --exclude-field <name|path|description|...> or --ignore-field <name|path|description|...>
• --exclude-fields [<name|path|description|...>,...] or --ignore-fields [<name|path|description|...>,...]
• might be tedious, but a clearer name and more explicit behavior: --search-fields [<name|path|description|...>,...]

[arcuru]

1. I will echo the idea that --plain would be a useful flag, and that the nix search --json | jq pipe is not a reasonable alternative. I think the UX gain of the flag will probably be worth the maintenance burden.
2. I think that generalizing the "ignore" piece of this would be a good idea, as @abathur suggested.

To maintainers, maybe you'd like this PR to be split?