Re: Improve package search

[Tobias Geerinckx-Rice]

Leo, mikadoZero,

This has been suggested many times and is a good idea.  Now all we 
need is someone to do the work, but that's the easy part, right?

Leo Famulari wrote:
> On Thu, Mar 14, 2019 at 02:31:36PM -0400, mikadoZero wrote:
> > # Proposed idea
> >
> > * Add a "programs" field to package definitions that list the 
> > programs
> >   that are included in a package. 
> > * Include this field in search results.
> > * Have this field factor into the search result relevance 
> > scores.

We should also expose it directly like other package managers do. 
‘guix which’ would be very handy, and allows 
‘command-not-found’-style suggestions for those who like that kind 
of thing.

> > # Feedback
> >
> > This is an initial idea that would benefit from the input of 
> > others.
>
> For me, it would be better to have this "program listing" built
> automatically, rather than relying on packagers to get it right 
> and keep
> it up to date. It would be a great feature once it is in place.

Absolutely.  Adding this to the package record manually is a 
maintenance nightmare.  It's data that can be trivially 
auto-generated (ls …/{,s}bin, basically), and storing it in-line 
takes up too much screen and mind space for my taste.

People have suggested using the build farm for this, but that adds 
disproportionate complexity and decouples/delays updates from the 
commits that caused them.  It's just not the right place.

A separate simple (text) database (included in the git repository, 
and updated in the same commit) would be faster to search and stay 
out of our way.

On the other hand, we'd be able to map commands only to package 
names, not to specific objects.

Just thinking out loud,

T G-R