Re: Build determinism, dependency granularity, and dependency scope

[Stephen Scheck]

On Wed, Nov 25, 2020 at 6:15 PM Leo Famulari <leo@famulari.name> wrote:

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

Java-based Guix packages also suffer from this problem (actually, I'm far
more familiar with dependency management in the JVM landscape than for Go,
but the use of granularly versioned and scoped, distributed dependency
models by both languages appears to be similar on the surface).

For example, the `java-log4j-core` Guix package (at version 2.4.1 in the
Guix tree) has a dependency on `java-fasterxml-jackson-core` (at version
2.9.4), but the corresponding Log4j release asserts a dependency version of
2.6.2 in its `pom.xml` [1].


> 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 case of the Go application I was trying to package, it does not
include vendored dependencies. And I don't have any relationship or
check-in privileges with the project - it is simply something I wanted to
use in an environment with other Guix-sourced packages. Well, I guess it
would be straightforward to fork the GitHub source, run `go mod vendor` [2]
and check in the vendor directory with a specific tag such as
"vx.y.z-guix-vendored". Whether the project maintainers would accept such a
pull request, or if it would be considered bad form to refer to a forked
repository in a Guix package definition instead of the official repo if
not, I don't know.

In the long run, Guix's Go support needs a complete overhaul.
>

Indeed.

[1] https://github.com/apache/logging-log4j2/blob/rel/2.4.1/pom.xml#L177
[2] https://golang.org/ref/mod#vendoring