From: Francois.JOULAUD--- via <help-guix@gnu.org>
To: Helio Machado <0x2b3bfa0@gmail.com>,
Timmy Douglas <mail@timmydouglas.com>
Cc: Katherine Cox-Buday <cox.katherine.e@gmail.com>,
"help-guix@gnu.org" <help-guix@gnu.org>
Subject: Re: packaging a golang package
Date: Mon, 25 Jan 2021 20:49:02 +0000 [thread overview]
Message-ID: <20210125204534.ovhvt7rzj7tbqrnt@fjo-extia-HPdeb.example.avalenn.eu> (raw)
In-Reply-To: <CANe01w6HZv4=n4HmfdtZECb78wT5SDA8PafbKmntgqDwav-yWA@mail.gmail.com>
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
next prev parent reply other threads:[~2021-01-25 20:55 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-08 7:01 packaging a golang package Timmy Douglas
2021-01-08 18:33 ` raingloom
2021-01-08 19:01 ` Leo Famulari
2021-01-10 0:32 ` Timmy Douglas
2021-01-11 6:09 ` Timmy Douglas
2021-01-17 13:31 ` Helio Machado
2021-01-25 7:18 ` Timmy Douglas
2021-01-25 20:49 ` Francois.JOULAUD--- via [this message]
2021-01-25 23:38 ` Helio Machado
2021-01-27 14:31 ` Katherine Cox-Buday
2021-01-28 8:18 ` Timmy Douglas
2021-01-28 10:32 ` adfeno--- via
2021-01-28 16:03 ` Ludovic Courtès
2021-01-28 21:10 ` adfeno--- via
-- strict thread matches above, loose matches on Subject: below --
2021-01-20 3:27 jgart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210125204534.ovhvt7rzj7tbqrnt@fjo-extia-HPdeb.example.avalenn.eu \
--to=help-guix@gnu.org \
--cc=0x2b3bfa0@gmail.com \
--cc=Francois.JOULAUD@radiofrance.com \
--cc=cox.katherine.e@gmail.com \
--cc=mail@timmydouglas.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).