Re: Understanding a Golang importer error

[Felix Lechner via "Development of GNU Guix and the GNU System distribution." <guix-devel@gnu.org>]

Hi Simon,

On Mon, May 22, 2023 at 10:02 AM Simon Tournier
<zimon.toutoune@gmail.com> wrote:
>
> Using submission #63647 [1], now it raises:
>
> --8<---------------cut here---------------start------------->8---
> $ ./pre-inst-env guix import go -r github.com/google/certificate-transparency-go
> guix import: warning: Git error: reference 'refs/tags/v0.41.1' not found in https://github.com/open-telemetry/opentelemetry-go-contrib
> guix import: warning: Git error: reference 'refs/tags/v2.305.9' not found in https://github.com/etcd-io/etcd
> following redirection to `https://github.com/bufbuild/protoc-gen-validate?go-get=1'...
> guix import: warning: Git error: reference 'refs/tags/v1.9.1' not found in https://github.com/googleapis/google-cloud-go
> guix import: warning: Git error: reference 'refs/tags/v1.14.0' not found in https://github.com/googleapis/google-cloud-go
> guix import: warning: Git error: reference 'refs/tags/v1.19.3' not found in https://github.com/googleapis/google-cloud-go
> --8<---------------cut here---------------end--------------->8---
>
> Note that these warnings are non-blocking and thus a list of Guix
> packages can be generated, although some are partial.

Thank you so much! That patch takes the cake and probably deserves to
become the accepted answer.

I would find it more consistent, however, to pick a nearby version (or
the newest version) and emit that package definition, instead.

After all, Guix package variables do not care about versions, and
neither do we. Guix and its contributors assume more or less
throughout that nearby versions work fine. Why not here, too?

We could also prompt the user of 'guix import' to select a tag.

> Well, I do not know if we can do better.  I mean, the issue seems about
> a wrong packaging upstream.  I mean, the tag v0.41.1 is reported as
> metadata from goproxy (https://proxy.golang.org) but then the real Git
> repository of the package does not contain it.

There must be a convention that were are missing. The repositories
contain hundreds and sometimes thousands of Git tags that look like
file paths. The version number we recognize are at the very end. At
the other end of the weirdness spectrum is the speculation by folks on
#go-nuts that the missing tags were subsequently deleted.

Do the versions perhaps come from the consuming go.mod files that
spell out the version requirements?

Kind regards,
Felix