1 |
On Mon, Sep 16, 2019 at 11:01:38AM -0700, Zac Medico wrote: |
2 |
> On 9/16/19 7:17 AM, William Hubbs wrote: |
3 |
> > +# You will know the software you are packaging uses modules because |
4 |
> > +# it will have files named go.sum and go.mod in its top-level source |
5 |
> > +# directory. If it does not have these files, use the golang-* eclasses. |
6 |
> > +# |
7 |
> > +# If the software you are packaging uses modules, the next question is |
8 |
> > +# whether it has a directory named "vendor" at the top-level of the source tree. |
9 |
> > +# |
10 |
> > +# If it doesn't, you need to create a tarball of what would be in the |
11 |
> > +# vendor directory and mirror it locally. |
12 |
> > +# If foo-1.0 is the name of your project and you have the tarball for it |
13 |
> > +# in your current directory, this is done with the following commands: |
14 |
> > +# |
15 |
> > +# @CODE: |
16 |
> > +# |
17 |
> > +# tar -xf foo-1.0.tar.gz |
18 |
> > +# cd foo-1.0 |
19 |
> > +# go mod vendor |
20 |
> > +# cd .. |
21 |
> > +# tar -acf foo-1.0-vendor.tar.gz foo-1.0/vendor |
22 |
> |
23 |
> For packages that I maintain, I'd prefer to continue using EGO_VENDOR to |
24 |
> even with packages using go.mod. I hope that this go-module.class will |
25 |
> not preclude this sort of usage. For example, the latest go-tools ebuild |
26 |
> uses EGO_VENDOR together with GOFLAGS="-mod=vendor": |
27 |
> |
28 |
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8cc6d401139526e2f9a6dbadbd31f0ff2387705f |
29 |
|
30 |
Can you elaborate on why you want to keep EGO_VENDOR? |
31 |
|
32 |
The "go mod vendor" command above downloads all the correct versions |
33 |
of the dependencies and puts them in the vendor directory, so I'm not |
34 |
sure why you would need the EGO_VENDOR variable. |
35 |
|
36 |
Thanks, |
37 |
|
38 |
William |