Hi Carlo, On Wed, 05 Mar 2025 20:52:21 +0800, Carlo Zancanaro wrote: > > [1 <text/plain (7bit)>] > Hi Guix! > > I recently got annoyed at trying to update two separate golang packages > in Guix (docker-compose and restic). I used "guix import go --recursive" > to try to build Guix package definitions for the dependencies they > needed, but it took hours and the result would have been labour > intensive to fix. > > I had a look at how Nix packages things, and saw that they do a > multi-stage build. > > First, they build a fixed-output derivation using "go mod vendor". This > pulls in all the dependencies exactly as the project requests them in > its go.mod file. > > Second, they do the actual package build, copying the above into the > "vendor" directory in the source. This lets the compiler find the > dependencies where it expects them. > > I figured this might be a good idea, so I wrote a package definition for > docker-compose and it works pretty well! I've attached my self-contained > test file. > > My question is: if I clean this up, how likely would it be to be merged > into Guix? I can see one discussion in the list history which mentions > doing this[1], but the conversation seems to have moved on without > seriously discussing the approach. > > I'm hoping that providing a working implementation here will > reinvigorate discussion about packaging applications with this approach. > I think it would lower the barrier to packaging substantially, at the > cost of being harder to reason about the dependencies of our packages. > > Carlo > > [1]: https://lists.gnu.org/archive/html/help-guix/2021-01/msg00203.html
Some issues to address in my mind: 1. Ability to unbundle individual dependency. We should be able to modify specefic dependencies. 2. Ability to verify licenses of dependencies. A dependency may be non-free or without a license. Bouns point: 3. Deduplication of downloads for individual dependency. Thanks
