Subject: bug#35551: guix search

From: Ludovic Courtès <[email-masked]>
Date: Mon, 13 May 2019 09:57:50 +0200

Hi Mark,

Mark H Weaver <[email-masked]> skribis:

> Bruno Haible <[email-masked]> writes:
>
>> Mark H Weaver wrote:
>>> If we add functionality that calls out to the network in response to a
>>> package search, e.g. to query popularity ratings or package file
>>> listings, we should make sure the user knows it's happening, and provide
>>> a way to disable it.  Some users may not want information about their
>>> package searches to be leaked to the outside world.
>>
>> Good point.
>>
>> Would it be more acceptable, upon 'guix search', to download an incremental
>> update of a package popularity database, and do the search locally? This
>> way, only the fact that the user has been doing a 'guix search' would be
>> leaked to the outside world, not the search term.
>
> Yes, that would address my concerns, although popularity ratings might
> be compact enough and change slowly enough that it might be sufficient
> to simply have them embedded in the Guix source code and manually
> updated periodically.
>
> Popularity ratings would also be useful to set build priorities on our
> build farms.
>
> The package file listings, on the other hand, are likely to be so large
> that it's not practical to download an incremental update of all of
> them.

FWIW, I like that there’s a purely off-line mode for ‘guix search’, as
is currently the case (after all, none of Guix relies on any single
service so far, and I think that’s a nice property.)

However, I think it’d be nice to have the option to enhance search
results by resorting to external services—just like using a substitute
service “enhances” the user experience.

I agree that the approach should rather be to download a complete
database and operate locally on it, rather than give the exact query to
the server.

Thanks,
Ludo’.