On Mon, 2019-09-16 at 17:00 -0500, William Hubbs wrote:
> 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.
> 

That sounds like a bad idea.  If there are any potential enhancements
that can happen, I'd rather see them happen before there's a bunch of
ebuilds using the eclass in the wild, and potentially limiting possible
changes.

-- 
Best regards,
Michał Górny