bug#35551: guix search

[Bruno Haible]

Hi Ludo,

> I would hope that ‘guix search’ and ‘guix package --list-available’ are
> easier than anything else, and that people value the idea of doing
> things locally.  Also, a local search gives the right result while a
> remote service might give results for a different Guix revision.
> 
> Is there any specific reason why you were uncomfortable with these
> commands?  I’m curious how we could improve the user experience here.

Yes. I was looking for a package that contains the 'ssh' command.
$ guix search ssh | less
returns libssh, libssh2, guile2.0-ssh, guile-ssh, sshpass, ...,
emacs-counsel-tramp.
The answer I was looking for was 'openssh', but it was hidden
among 66 packages.

A search is good if the relevant results for the user occur
among the first screen.

Possible improvements include:

1) If the search term is X and installing the package would cause
   a program named X to appear in $PATH, then list this package first.

   This rule would have listed 'openssh' first. Also, for 'guix search gcc',
   it would now make 'gcc-toolchain' appear first (right?).

2) Another heuristic for presenting the "best" hits first:
   Sort the graph of the packages (using dependencies as graph edges).
   Then present the "base" packages (the packages which don't depend on
   other packages) first.

   This will likely make packages that are bindings (guile-ssh, ruby-net-ssh,
   etc.) appear after openssh.

3) If the resulting list is longer than one screenful, present only the
   names, not names + details. Like
     $ guix search ssh | grep '^name:'
   would do.
   Even without the improvements 1) and 2), the command
     $ guix search ssh | grep '^name:' | grep ssh | sort
   produces a one-screenful result that I could have evaluated in 10 seconds.

Bruno