Re: packaging a golang package

[Francois.JOULAUD--- via <help-guix@gnu.org>]

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