On Thu, 06 Mar 2025 07:11:56 +0800, Carlo Zancanaro wrote: > > 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.
I understand that feeling. I agree current packaging model doesn't suits Go ecosystem well. I also have a ‘go mod vendor’-based fetcher implementation kept in my notes. But as a distribution, knowing little about dependencies is not a good sign. > 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. go-licenses seems useful, it's acceptable as long as it's reliable and the result can be verified by anyone. > > 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 On Thu, 06 Mar 2025 15:04:25 +0800, Efraim Flashner wrote: > > This seems like something that could benefit from the changes being > proposed to the rust ecosystem in Guix :). Let's continue the topic here[1] :) [1]: https://lists.gnu.org/archive/html/guix-devel/2025-02/msg00504.html
