On Wed, Nov 25, 2020 at 6:15 PM Leo Famulari <l...@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
