On Fri, Nov 27, 2020 at 02:08:19PM -0500, Stephen Scheck wrote: > 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].
Yes, sounds quite similar... more room for improvement. > 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. Right, that should work, and would be a good way to get started for a "private" package, but we (Guix) really need to improve our tools here. On that note... I just remembered we have a WIP patch that adds a recursive Go module importer: https://bugs.gnu.org/44178 I encourage you to try it out! I see you have a patch in Guix, so maybe you learned how to apply patches and use the 'pre-inst-env' script to test them, as described in the manual section Contributing? Please don't hesitate to ask for help :) I think the ideal solution is to combine recursive module importing with the "dependency constructor".
