From: Leo Famulari <leo@famulari.name>
To: Stephen Scheck <singularsyntax@gmail.com>
Cc: help-guix <help-guix@gnu.org>
Subject: Re: Build determinism, dependency granularity, and dependency scope
Date: Wed, 25 Nov 2020 18:15:54 -0500 [thread overview]
Message-ID: <20201125231554.GD2093@jasmine.lan> (raw)
In-Reply-To: <CAKjnHz0gOpW8PZj-XUN8OsP1c-CPiSjZjRXrFurKOQWEw56=kg@mail.gmail.com>
On Tue, Nov 24, 2020 at 04:20:35PM -0500, Stephen Scheck wrote:
> 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`.
Right.
> Am I missing something here?
No. The way that dependencies are handled in Go-world does concord with
Guix on a conceptual level — it's definitely possible to have hundreds
of versions of each Go library — but it's impractical with the current
Guix tooling.
> 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"))
> ;; ... )
Yes, I've suggested something like this before (somewhere in the mailing
list archives). The specifications would also need to include the source
hash, but otherwise we've come to the same conclusion. Ideally, they
would be generated automatically from go.mod.
Previously, I made sure these "standard" Go libraries matched the
versions specified by Syncthing, since I maintained that package
carefully. Since Syncthing switched to Go modules, I haven't found the
time to rework Guix's go-build-system to work correctly, and I haven't
paid attention to what's been happening with Go on Guix.
A good stopgap option is to use vendored dependencies (heresy, I know),
assuming they are free software and the upstream sources include them.
This works fine and is better than not having Go software at all.
In the long run, Guix's Go support needs a complete overhaul.
next prev parent reply other threads:[~2020-11-25 23:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-24 21:20 Build determinism, dependency granularity, and dependency scope Stephen Scheck
2020-11-25 22:39 ` raingloom
2020-11-27 18:38 ` Stephen Scheck
2020-11-25 23:15 ` Leo Famulari [this message]
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=20201125231554.GD2093@jasmine.lan \
--to=leo@famulari.name \
--cc=help-guix@gnu.org \
--cc=singularsyntax@gmail.com \
/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).