Re: [gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules

[Zac Medico <zmedico@gentoo.org>]

[-- Attachment #1.1: Type: text/plain, Size: 3784 bytes --]

On 9/17/19 7:10 AM, William Hubbs wrote:
> On Tue, Sep 17, 2019 at 07:36:07AM +0200, Michał Górny wrote:
>> 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.
> 
> Like I just said on IRC, it would have been better if you responded in
> terms of discussing the enhancement itself.
> 
> The main blocker for me is that EGO_VENDOR is basically the same
> information as go.mod, but it isn't quite the same format.
> You can get close with "go list -m all", but EGO_VENDOR doesn't
> automatically handle imports that start with things like golang.org/x or
> gopkg.in; you have to manually fix those, and you would have to do that
> every time. That seems to be a lot of work for little gain.

It looks like it should not be too difficult to create a script that
will convert from go.mod to EGO_VENDOR format. For example, take this
go.mod file:

    https://github.com/golang/tools/blob/master/go.mod

It contains a line like this:

    golang.org/x/net v0.0.0-20190620200207-3b0461eec859

The part after the last hyphen corresponds to the commit hash which can
be used directly or expanded like this:

    $ curl -sS https://api.github.com/repos/golang/net/commits/3b0461eec859 | jq -r .sha
    3b0461eec859c4b73bb64fdc8285971fd33e3938

The github owner and repo names can resolved like this:

    $ curl -sS https://golang.org/x/net | grep go-source
    <meta name="go-source" content="golang.org/x/net https://github.com/golang/net/ https://github.com/golang/net/tree/master{/dir} https://github.com/golang/net/blob/master{/dir}/{file}#L{line}">

I've found that `go get` parses a similar meta element named "go-import"
here:

    https://github.com/golang/go/blob/master/src/cmd/go/internal/get/discovery.go
-- 
Thanks,
Zac


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]