unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: Stephen Scheck <singularsyntax@gmail.com>
To: help-guix <help-guix@gnu.org>
Subject: Build determinism, dependency granularity, and dependency scope
Date: Tue, 24 Nov 2020 16:20:35 -0500	[thread overview]
Message-ID: <CAKjnHz0gOpW8PZj-XUN8OsP1c-CPiSjZjRXrFurKOQWEw56=kg@mail.gmail.com> (raw)

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

             reply	other threads:[~2020-11-24 21:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-24 21:20 Stephen Scheck [this message]
2020-11-25 22:39 ` Build determinism, dependency granularity, and dependency scope raingloom
2020-11-27 18:38   ` Stephen Scheck
2020-11-25 23:15 ` Leo Famulari
2020-11-27 19:08   ` Stephen Scheck
2020-11-28  2:30     ` Leo Famulari

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKjnHz0gOpW8PZj-XUN8OsP1c-CPiSjZjRXrFurKOQWEw56=kg@mail.gmail.com' \
    --to=singularsyntax@gmail.com \
    --cc=help-guix@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).