help-guix
[Top][All Lists]
Advanced

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

Re: Build determinism, dependency granularity, and dependency scope


From: raingloom
Subject: Re: Build determinism, dependency granularity, and dependency scope
Date: Wed, 25 Nov 2020 23:39:05 +0100

On Tue, 24 Nov 2020 16:20:35 -0500
Stephen Scheck <singularsyntax@gmail.com> wrote:

> I have been trying to package an open source application written in
> Go for Guix, and along the way as I've come to understand the
> mechanics better, I've realized a few things which are a bit
> disconcerting. I'll refer to the package for Yggdrasil, as it was
> recommended to me as a good blueprint to follow for the project I'm
> trying to package.
> 
> If you take a look at the package definition for Yggdrasil 0.3.15,
> here are some of the Golang dependencies:
> 
>     (propagated-inputs
>        ;; ...
>        ("go-golang-org-x-net" ,go-golang-org-x-net)
>        ("go-golang-org-x-text" ,go-golang-org-x-text)
>        ;; ... )
> 
> If you look at the project's `go.mod` file [1], you have:
> 
>     golang.org/x/net v0.0.0-20200301022130-244492dfa37a
>     golang.org/x/text v0.3.3-0.20191230102452-929e72ca90de
> 
> But if you look at the commits for the packages defined in the Guix
> tree, they do not correspond. And the `go-golang-org-x-text` package
> in the Guix tree (version "0.3.2") does not even meet the minimum
> version specified in `go.mod`.
> 
> Also, it occurs to me that someone could decide to bump the version
> for one of these packages up in the global Guix tree at any time to
> satisfy the version requirements of some other package which require
> a newer version, but because at the single package level there is
> only a reference to the package name but not the version, all
> dependencies in the tree will be carried along for the ride (!).
> 
> Now, there's nothing preventing someone from defining versioned
> packages in the Guix tree, such as a
> `go-golang-org-x-text-929e72ca90de`, and referring to those in
> dependent packages, but in practice that doesn't seem to be done and
> most packages appear to have only one version, except for some things
> like major language/platform versions (e.g. openjdk).
> 
> Am I missing something here?
> 
> It seems like what is needed would something like a package-scoped
> "dependency constructor", allowing you to declare required versions
> per-package:
> 
>     (propagated-inputs
>        ;; ...
>        ("go-golang-org-x-net" (go-module "golang.org/x/net"
> "244492dfa37a")) ("go-golang-org-x-text" (go-module
> "golang.org/x/text" "929e72ca90de"))
>        ;; ... )
> 
> [1]
> https://github.com/yggdrasil-network/yggdrasil-go/blob/v0.3.15/go.mod

Multiple versions leads to more maintenance burden and a bigger store.

But I admit I didn't really investigate which exact module versions
Yggdrasil is compatible with.



reply via email to

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