Re: Build determinism, dependency granularity, and dependency scope

[Leo Famulari]

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.