Hello, On Sun, Jan 17, 2021 at 02:31:39PM +0100, Helio Machado wrote: > Looks like it ran into the replace syntax and didn't parse it correctly? > > https://golang.org/ref/mod#go-mod-file
New version of the patch on https://issues.guix.gnu.org/issue/44178#10 fixes some of those problems. There is still others bugs left but you could give it a new try. Git repo with patch applied is available at [6] > Guix seems to have a strong opinion about dependency vendoring, but it's > technically viable as long as you don't produce architecture-specific > artifacts when packaging. See https://issues.guix.info/43872 for more > information about the pitfalls I encountered while packaging go-ethereum > the fast way. It seems to me we have three possible ways to handle Go packaging. First is to use vendored dependencies (when upstream provides them). This one has the merits of simplicity (as we just have to download the source and launch `go build` or whatever is needed) and less risks of bugs. The downsides are known: difficult to audit Licences, duplication of code source, difficulty to follow security bugs, etc. Second is to re-vendor package from go.mod (coming directly from code source or synthetized from source) by creating a source derivation including all dependencies. This is the strategy followed by Nixpkgs as explained in [1]. (It seems to me this is the route followed in the patches to from Helio in [2] but I did not take the time to read them.) With this approach we still have some of the downsides of using vendored upstream but it is at least easier to verify the existence of upstream. Third is to package every dependencies. This is the most transparent way and the one that leads to less code duplication but the downside is the difficulty to scale with the number of packages (even if the objective of patch at [3] is to automate it) and the need to have only one reference version for each package in the distribution which have its own share of problems (one of them being that we don't use those tested by upstream as stated in [4]). I think Guix should support all three in its tooling to be able to support several use-cases. For inclusion of packages in Guix proper we should try the individual packaging of dependencies and see how it works. Perhaps we will need exceptions as the one Debian does for Kubernetes [5]. Perhaps we will need to fallback to vendoring or re-vendoring in more cases but we will learn as we walk. Best regards, François [1]: https://github.com/NixOS/nixpkgs/issues/84826 [2]: https://github.com/0x2b3bfa0/guix-go-modules/commit/5defe897065c5d3e63740932b360474132c77877 [3]: https://issues.guix.gnu.org/issue/44178#10 [4]: https://github.com/NixOS/nixpkgs/issues/84826#issuecomment-616663815 [5]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971515 [6]: https://github.com/kat-co/guix/tree/create-go-importer
