This back and forth is what I've been having going on in my head.  We might be able to leverage repology.org for their work on mapping packages across distros.  Yesterday, civodul entered a bug to remove the Etag and last-modified headers in the nginx config to fix a bug on our side so repology will update info on guix.  That code is GPL'd so some of it could be incorporated, and maybe even be leveraged to interpret foreign distro's packages to create package prototypes which we could then use to more rapidly expand what packages are available through guix.  I could see this as a high-payoff medium effort development for guix.

On Sun, May 10, 2020 at 9:34 AM zimoun <zimon.toutoune@gmail.com> wrote:
Hi Julien,

On Sun, 10 May 2020 at 14:13, Julien Lepiller <julien@lepiller.eu> wrote:

> The proposal was about suggesting anotger nameqwhen no package was found, not to install something else.

Sorry I misinterpreted.


> >Well, do you have specific example in mind?
>
> $ guix install gcc
> guix install: error: gcc: unknown package
> Hint: did you mean `guix install gcc-toolchain`?
>
> Since not being able to install gcc is surprising, and you don't always know about gcc-toolchain.

I understand even if this one is the wrong example. :-)
It even deserves an entry in the manual.
Well, but I understand what you mean.


> $ guix install gpg
> Hint: did you mean `guix install gnupg`?

The question is: why do you type 'gpg'?

I mean, the upstream name is really GnuPG so it is not one "stupid"
Guix devs arbitrary rename because in their infinite wisdom they
decided to. ;-)

Well, do you type 'gpg' because
a) it is the name of the binary?
or b) it is the name of the package in your previous favourite distro?

If it is a), then a proposal by Pierre named "filesearch" is floating
around.  And this should improve the situation.

If it is b), then I do not see how to improve the situation in the
general case.  But maybe there is some well-known cases.


> Often a name is used to refer to a package, and it's annoying to go through a search, especially when you have to filter a big output.

I agree.  From my point the issue is that "guix search" is not doing
the job and the improvement should come from this.  And your 'gpg'
example is a good one, IMHO:

--8<---------------cut here---------------start------------->8---
$ guix search gpg | recsel -C -p name,relevance
name: signing-party
relevance: 16
name: qgpgme
relevance: 15
name: libgpg-error
relevance: 14
name: python2-gpg
relevance: 11
name: python-gpg
relevance: 11
name: ledger-agent
relevance: 9
name: python2-pygpgme
relevance: 8
name: python-pygpgme
relevance: 8
name: gpgme
relevance: 8
name: kgpg
relevance: 6
name: jetring
relevance: 6
name: emacs-pinentry
relevance: 6
name: trezor-agent
relevance: 5
name: python-trezor-agent
relevance: 5
name: keepkey-agent
relevance: 5
name: qtpass
relevance: 2
name: pinentry
relevance: 2
name: pinentry-tty
relevance: 2
name: pinentry-qt
relevance: 2
name: pinentry-gtk2
relevance: 2
name: pinentry-gnome3
relevance: 2
name: pinentry-emacs
relevance: 2
name: pinentry-efl
relevance: 2
name: kleopatra
relevance: 2
name: gnupg
relevance: 2
name: gnupg
relevance: 2
name: git-remote-gcrypt
relevance: 2
name: gajim
relevance: 2
name: emacs-extend-smime
relevance: 2
name: assword
relevance: 2
--8<---------------cut here---------------end--------------->8---

The expected package 'gnupg' appears... piouf!

I fully agree that the experience with "guix search" is frustating.
And maybe using both the 'upstream-name' and an extra 'properties'
such as 'alternative-names' or 'extra-keywords' should help for
discoverability.


WDYT?

All the best,
simon