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