1 |
On Tue, Sep 17, 2019 at 07:36:07AM +0200, Michał Górny wrote: |
2 |
> On Mon, 2019-09-16 at 17:00 -0500, William Hubbs wrote: |
3 |
> > On Mon, Sep 16, 2019 at 11:50:12AM -0700, Zac Medico wrote: |
4 |
> > > On 9/16/19 11:35 AM, William Hubbs wrote: |
5 |
> > > > On Mon, Sep 16, 2019 at 11:01:38AM -0700, Zac Medico wrote: |
6 |
> > > > > For packages that I maintain, I'd prefer to continue using EGO_VENDOR to |
7 |
> > > > > even with packages using go.mod. I hope that this go-module.class will |
8 |
> > > > > not preclude this sort of usage. For example, the latest go-tools ebuild |
9 |
> > > > > uses EGO_VENDOR together with GOFLAGS="-mod=vendor": |
10 |
> > > > > |
11 |
> > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8cc6d401139526e2f9a6dbadbd31f0ff2387705f |
12 |
> > > > |
13 |
> > > > Can you elaborate on why you want to keep EGO_VENDOR? |
14 |
> > > > |
15 |
> > > > The "go mod vendor" command above downloads all the correct versions |
16 |
> > > > of the dependencies and puts them in the vendor directory, so I'm not |
17 |
> > > > sure why you would need the EGO_VENDOR variable. |
18 |
> > > |
19 |
> > > EGO_VENDOR eliminates to need to generate and host monolithic tarballs |
20 |
> > > containing vendored dependencies. It's more space-efficient in the sense |
21 |
> > > that each vendored dependency is stored in a separate tarball, so |
22 |
> > > multiple ebuilds can share the same tarball if the version of a |
23 |
> > > particular vendored dependency has not changed. |
24 |
> > |
25 |
> > I see what you are saying, but I haven't yet found a way to generate |
26 |
> > these separate tarballs that I'm comfortable with. Also, thinking about |
27 |
> > this, there will be many more tarballs on our mirrors if we store one |
28 |
> > dependency in each tarball than if we generate vendor tarballs that |
29 |
> > contain all dependencies for a package. |
30 |
> > |
31 |
> > I would consider this an enhancement to the eclass if you still feel |
32 |
> > that we need it, but let me get the eclass into the tree first then we |
33 |
> > can work on that. |
34 |
> > |
35 |
> |
36 |
> That sounds like a bad idea. If there are any potential enhancements |
37 |
> that can happen, I'd rather see them happen before there's a bunch of |
38 |
> ebuilds using the eclass in the wild, and potentially limiting possible |
39 |
> changes. |
40 |
|
41 |
Like I just said on IRC, it would have been better if you responded in |
42 |
terms of discussing the enhancement itself. |
43 |
|
44 |
The main blocker for me is that EGO_VENDOR is basically the same |
45 |
information as go.mod, but it isn't quite the same format. |
46 |
You can get close with "go list -m all", but EGO_VENDOR doesn't |
47 |
automatically handle imports that start with things like golang.org/x or |
48 |
gopkg.in; you have to manually fix those, and you would have to do that |
49 |
every time. That seems to be a lot of work for little gain. |
50 |
|
51 |
William |