On Mon, Sep 16, 2019 at 11:01:38AM -0700, Zac Medico wrote:
> On 9/16/19 7:17 AM, William Hubbs wrote:
> > +# You will know the software you are packaging uses modules because
> > +# it will have files named go.sum and go.mod in its top-level source
> > +# directory. If it does not have these files, use the golang-* eclasses.
> > +#
> > +# If the software you are packaging uses modules, the next question is
> > +# whether it has a directory named "vendor" at the top-level of the source tree.
> > +#
> > +# If it doesn't, you need to create a tarball of what would be in the
> > +# vendor directory and mirror it locally.
> > +# If foo-1.0 is the name of your project and you have the tarball for it
> > +# in your current directory,  this is done with the following commands:
> > +#
> > +# @CODE:
> > +#
> > +# tar -xf foo-1.0.tar.gz
> > +# cd foo-1.0
> > +# go mod vendor
> > +# cd ..
> > +# tar -acf foo-1.0-vendor.tar.gz foo-1.0/vendor
> 
> 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.

Thanks,

William