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
docker-compose.scm
Description: Binary data
