Hi Bruno, Bruno Haible <br...@clisp.org> skribis:
>> 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. I see. > 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?). I agree that this would be great, but we don’t know beforehand what commands a package provides. For that we’d need to resort to an external service providing this info. > 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. This sounds like an interesting option, at least when one is searching for an application and not for a library. > 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. OK, though you would have been unable to see the descriptions. Another option I thought of would be to display only the 10 results with the highest relevance by default, when stdout is a terminal. Thoughts? Thanks, Ludo’.
