Thank you, Ludovic. It will be nice to have some additional fields computed with Internet databases like:
Tag->name Tag->Relevance Purpose: editor, viewer, library, development tool Interface: gui app, console-only, console and gui, system calls For every tag needs to determine relevance. For example, package VLC: Tag->name: video Tag->relevance: 100 Tag->name: view Tag->relevance: 90 and other tags Purpose: viewer Interface: gui app This can give additional options for search or just improve sorting when user type f.e. ' guix search video viewer' May 13, 2019 7:58 AM, "Ludovic Courtès" <[email protected]> wrote: > Hi Mark, > > Mark H Weaver <[email protected]> skribis: > >> Bruno Haible <[email protected]> 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’.
