guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Understanding a Golang importer error


From: Simon Tournier
Subject: Re: Understanding a Golang importer error
Date: Thu, 25 May 2023 16:09:58 +0200

Hi,

On mer., 24 mai 2023 at 19:29, Felix Lechner via "Development of GNU Guix and 
the GNU System distribution." <guix-devel@gnu.org> wrote:

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

Well, what does it mean “nearby“?  From my understanding, it seems
better to display a warning, to be non-blocking and provide a recipe
where the integrity checksum is missing.  For an example, see:

    https://issues.guix.gnu.org/issue/63647#0-lineno61


> 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?

I do not understand what it means.  Guix package cares a lot about
fixed-output, i.e. about the integrity checksum. :-) Quoting the manual:

        Operations such as file downloads and version-control checkouts
        for which the expected content hash is known in advance are
        modeled as fixed-output derivations. Unlike regular derivations,
        the outputs of a fixed-output derivation are independent of its
        inputs—e.g., a source code download produces the same result
        regardless of the download method and tools being used.

        https://guix.gnu.org/manual/devel/en/guix.html#Derivations

Therefore, you need a mean to express the map between the Guix
content-addressed and the outside world working with URIs and often with
version label.


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

Well, I know nothing about Go.  Neither about how Go packaging is
working.  Currently, these tags does not seems appearing in the goproxy
(https://proxy.golang.org) which is the information used to construct
the recipe, IIUC.


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

Please note that, as Attila pointed, some improvements [1,2] for the Go
importer are waiting for review in the patch tracker.  Help is
welcome. ;-)

1: https://issues.guix.gnu.org/issue/55242
2: https://issues.guix.gnu.org/issue/63631


Cheers,
simon



reply via email to

[Prev in Thread] Current Thread [Next in Thread]