Hi Hilton, Before I respond to your specific concerns, I just want to clarify my aim.
I'm not trying to say "all Go code should be packaged like this", I'm just trying to come up with a practical way to update applications which are currently unsupported. My prime example is the docker-compose package, which is from May 2021. Upstream dropped support of v1 (and the Python code base) at the end of June 2023. The v2 code base is in Go. Using the packaged 1.29.2 doesn't work for me at all (it complains while talking to the daemon), and I was totally overwhelmed by trying to update it using our current methods. Using the package definition sent in my prior email I can use docker compose again on my system. Thus, I think this idea should be compared to the packaging costs of our current system, which seem pretty high to me. I did a "guix import go --recursive" for restic (where our packaged version is from November 2019) and it gave me a list of 198 Go dependencies that would need to be packaged. To be blunt, I am unwilling to do the work needed to package them. On Wed, Mar 05 2025, Hilton Chain wrote: > 1. Ability to unbundle individual dependency. > > We should be able to modify specefic dependencies. I think we can do this. The <vendored-go-deps> record type could have an "unbundle" field with a list of package names to not include, and it can rewrite go.mod before fetching to exclude them. We would then also need a mechanism to provide the unbundled dependencies in the vendor/ folder, but this shouldn't need to be more than another phase to copy them in. For indirect dependencies this seems a lot harder, so I'd be inclined to say let's not do that. > 2. Ability to verify licenses of dependencies. > > A dependency may be non-free or without a license. This is more complicated. I think there are two lenses on this: asking "what can we package according to the FSDG?", and separately asking "what should we put in the license field"? If we're just interested in answering the question for the sake of knowing "is this free software?" we can likely use something like Go's licenses tool[1] to pull together all the licenses that are used by the package's dependency graph. While this isn't the same as auditing each package on the way, it should give a reasonable sense of the declared licenses for each Go package. If we're looking to work out what to put in the license field, then I think there's some ambiguity. There's always a question of "what does the license field represent", which has some ambiguity[2]. In this case, I'm not sure whether the license field should contain information about (recursive) dependencies. > 3. Deduplication of downloads for individual dependency. This seems harder to do. It might be possible to do by writing a server implementing the GOPROXY protocol[3] to reuse the downloads between builds. This would be a big jump in complexity. Given the sources aren't needed when packages are substituted, I wonder if this could be a future improvement rather than needing to be solved right away. Carlo [1]: https://github.com/google/go-licenses [2]: https://lists.gnu.org/archive/html/guix-devel/2021-05/msg00183.html [3]: https://go.dev/ref/mod#goproxy-protocol
