[Top][All Lists]

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

Re: Go importer and packages with version flags

From: Katherine Cox-Buday
Subject: Re: Go importer and packages with version flags
Date: Mon, 27 Sep 2021 21:53:04 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

Jack Hill <> writes:

> Hi Guix,

Hey, Jack, a few thoughts.

> While I was was working with the go importer today, it suggested I package
> go-github-com-russross-blackfriday-v2. Fair enough, except we already have a
> package for go-github-com-russross-blackfriday.

I was poking around a rust code-base the other day and I noticed our crate 
importer, and thus a lot of crate packages, have major-version suffixes. I 
think one of the unique benefits of Guix is that it can simultaneously have 
multiple versions of libraries installed, and I think we should allow this for 
library packages.

I know that leads to dependency graph explosion, but perhaps we only commit to 
substitutes for the latest version, and thus any packages using old versions. 
It should converge over time unless packages go unmaintained.

I thought our current stance was to only allow one version at a time, but the 
crate packages made me question this. I'd like clarity too.

> The packages differ in their version (2.1.0 verses 2.0.1), their imputs (the
> imported package definition is missing the inputs and native-inputs that we
> have in the Guix package), and the presense of the v2 versioning
> disambiguation tag.

The importer suggested package is correct. It looks like the listed 
dependencies dropped >= v1.5. See:


I wasn't sure if pkg.go listed test dependencies, so I ran this command to be 

$ go list -deps -test -f '{{.ImportPath}} {{.Standard}}' |awk '{if ($2 == 
"false")  print $1}'

I think those were just dependencies incorrectly carried over as the package 

I hope that helps.


reply via email to

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