Re: Build determinism, dependency granularity, and dependency scope

[Leo Famulari]

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