On Wed, Apr 01, 2020 at 11:30:00PM +0100, Samuel Bernardo wrote:
> Hi Robin,
>
> On 4/1/20 11:07 PM, Robin H. Johnson wrote:
> >>> # I am considering removing this and just hard coding mirror://goproxy
> >>> # below, so please do not rely on it.
> >>> : "${_GOMODULE_GOPROXY_BASEURI:=mirror://goproxy/}"|
> >> So, go-module.eclass provides a good base to follow SRP pattern (single
> >> responsibility principle). Looking into that effort I would copy
> >> go-module.eclass to my overlay eclass directory and adapt it to use my
> >> mirror type.
> >>
> >> I would like to use directly Gentoo maintained go-module.eclass, but for
> >> that I would like to have access to set my own mirror type.
> >>
> >> I also ask you to update documentation since there is some details to
> >> use EGO_SUM, such as you stated in comment[4].
> > It's not clear why you need to modify the mirror behavior at all; maybe
> > you covered that elsewhere in this overly long thread.
>
> Remembering that I'm in overlay context, lets consider the use case with
> a private repository with restricted access from where I need to get
> some go module. I need to use an alternative mirror not listed in
> default goproxy mirror type.
Ok, so what you're REALLY asking for here, is a cleaner way to specify
that a go module that exists OUTSIDE of the upstream Goproxy ecosystem.The eclass as it stands was written as a way to CONSUME the upstream Goproxy ecosystem efficiently, without producing a bundling mess. This is not entirely a Gentoo packaging problem, but also intersects upstream Go packaging, specifically that outside of the ebuild you have to take special measures to cause 'go mod' to fetch from your alternative mirror that contains private modules. Upstream also doesn't have a good handle on how to solve this problem for ALL of the edge cases (see GOPRIVATE and interactions with the GOSUMDB). Your package that consumes that go module PROBABLY also consumes many public go modules, so you don't want to modify or mirror every single entry: just the private ones. I propose the following rough improvement to the go-module.eclass for EGO_SUM usage in the above case. EGO_SUM=( "github.com/aybabtme/rgbterm v0.0.0-20170906152045-cc83f3b3ce59/go.mod" "github.com/aybabtme/rgbterm v0.0.0-20170906152045-cc83f3b3ce59" ) EGO_SUM_WITH_BASE=( "mirror://private/ internal.com/foo/disco v1.2.3/go.mod" "mirror://private/ internal.com/foo/disco v1.2.3" "https://site2/ mycompany.com/bar/dance v2.3.4/go.mod" "https://site2/ mycompany.com/bar/dance v2.3.4/" ) EGO_SUM can be trivially transformed to EGO_SUM_WITH_BASE, by adding the mirror://goproxy/ slug as a first argument. The implementation of go-module_set_globals remains almost identical, just using the new first argument rather than the ${_GOMODULE_GOPROXY_BASEURI} variable. -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136
signature.asc
Description: PGP signature
