[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.