Re: [gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules

[William Hubbs <williamh@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1700 bytes --]

On Mon, Sep 16, 2019 at 11:50:12AM -0700, Zac Medico wrote:
> On 9/16/19 11:35 AM, William Hubbs wrote:
> > On Mon, Sep 16, 2019 at 11:01:38AM -0700, Zac Medico wrote:
> >> For packages that I maintain, I'd prefer to continue using EGO_VENDOR to
> >> even with packages using go.mod. I hope that this go-module.class will
> >> not preclude this sort of usage. For example, the latest go-tools ebuild
> >> uses EGO_VENDOR together with GOFLAGS="-mod=vendor":
> >>
> >> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8cc6d401139526e2f9a6dbadbd31f0ff2387705f
> > 
> > Can you elaborate on why you want to keep EGO_VENDOR?
> > 
> > The "go mod vendor" command above downloads all the correct versions
> > of the dependencies and puts them in the vendor directory, so I'm not
> > sure why you would need the EGO_VENDOR variable.
> 
> EGO_VENDOR eliminates to need to generate and host monolithic tarballs
> containing vendored dependencies. It's more space-efficient in the sense
> that each vendored dependency is stored in a separate tarball, so
> multiple ebuilds can share the same tarball if the version of a
> particular vendored dependency has not changed.

I see what you are saying, but I haven't yet found a way to generate
these separate tarballs that I'm comfortable with. Also, thinking about
this, there will be many more tarballs on our mirrors if we store one
dependency in each tarball than if we generate vendor tarballs that
contain all dependencies for a package.

I would consider this an enhancement to the eclass if you  still feel
that we need it, but let me get the eclass into the tree first then we
can work on that.

Thanks,

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]