Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev@l.g.o
Cc: zmedico@g.o
Subject: Re: [gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules
Date: Tue, 17 Sep 2019 05:36:18
Message-Id: 35b14362c4ac77ffac5ff753becebd094dd994c3.camel@gentoo.org
In Reply to: Re: [gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules by William Hubbs
1 On Mon, 2019-09-16 at 17:00 -0500, William Hubbs wrote:
2 > On Mon, Sep 16, 2019 at 11:50:12AM -0700, Zac Medico wrote:
3 > > On 9/16/19 11:35 AM, William Hubbs wrote:
4 > > > On Mon, Sep 16, 2019 at 11:01:38AM -0700, Zac Medico wrote:
5 > > > > For packages that I maintain, I'd prefer to continue using EGO_VENDOR to
6 > > > > even with packages using go.mod. I hope that this go-module.class will
7 > > > > not preclude this sort of usage. For example, the latest go-tools ebuild
8 > > > > uses EGO_VENDOR together with GOFLAGS="-mod=vendor":
9 > > > >
10 > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8cc6d401139526e2f9a6dbadbd31f0ff2387705f
11 > > >
12 > > > Can you elaborate on why you want to keep EGO_VENDOR?
13 > > >
14 > > > The "go mod vendor" command above downloads all the correct versions
15 > > > of the dependencies and puts them in the vendor directory, so I'm not
16 > > > sure why you would need the EGO_VENDOR variable.
17 > >
18 > > EGO_VENDOR eliminates to need to generate and host monolithic tarballs
19 > > containing vendored dependencies. It's more space-efficient in the sense
20 > > that each vendored dependency is stored in a separate tarball, so
21 > > multiple ebuilds can share the same tarball if the version of a
22 > > particular vendored dependency has not changed.
23 >
24 > I see what you are saying, but I haven't yet found a way to generate
25 > these separate tarballs that I'm comfortable with. Also, thinking about
26 > this, there will be many more tarballs on our mirrors if we store one
27 > dependency in each tarball than if we generate vendor tarballs that
28 > contain all dependencies for a package.
29 >
30 > I would consider this an enhancement to the eclass if you still feel
31 > that we need it, but let me get the eclass into the tree first then we
32 > can work on that.
33 >
34
35 That sounds like a bad idea. If there are any potential enhancements
36 that can happen, I'd rather see them happen before there's a bunch of
37 ebuilds using the eclass in the wild, and potentially limiting possible
38 changes.
39
40 --
41 Best regards,
42 Michał Górny

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies