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
