On 2019/09/17 09:59, Eric Auge wrote: > then maybe GOPROXY=off (along side GOSUMDB=off otherwise the sumdb is > consulted over the net too)? as described in the go documentation (go > help modules / go help module-auth): > > module: > ... > Setting GOPROXY to "off" disallows downloading modules from any > source. Otherwise, GOPROXY is expected to be a comma-separated list of > the URLs of module proxies, in which case the go command will fetch > modules from those proxies. > ... > > sum db: > ... > If GOSUMDB is set to "off", or if "go get" is invoked with the > -insecure flag, the checksum database is not consulted > ...
I didn't know about that option, but testing it, I prefer the error message with what I committed, it's way more obvious what the problem is. "module lookup disabled by GOPROXY=off" -vs- "invalid proxy URL scheme (must be https, http, file): invalid://ports.should.not.fetch.at.buildtime/" (though I think with GO111MODULE=off we probably won't see it anyway). > HTH, > Cheers, > Eric. > > On Mon, Sep 16, 2019 at 11:03 PM Stuart Henderson <s...@spacehopper.org> > wrote: > > > > We don't want to just disable the proxy, we want to disable any network > > fetches, setting GOPROXY to an invalid url/scheme currently has that effect. > > > > -- > > Sent from a phone, apologies for poor formatting. > > > > On 16 September 2019 19:55:56 Eric Auge <eau+o...@unix4fun.net> wrote: > > > > > Hello, > > > > > > I think I saw an update of lang/go to 1.13, which introduce this > > > modules probing "stuff", read/taken from https://golang.org/doc/go1.13 > > > : > > > > > > """ > > > Users who cannot reach the default proxy and checksum database (for > > > example, due to a firewalled or sandboxed configuration) may disable > > > their use by setting GOPROXY to "direct", > > > and/or GOSUMDB to "off". go env -w can be used to set the default > > > values for these variables independent of platform: > > > > > > go env -w GOPROXY=direct > > > go env -w GOSUMDB=off > > > """ > > > > > > which seems would default to the commonly known (aka before go modules > > > and proxy bla) behaviour of the "go get" command, > > > using the cache first and then trying to resolve dependencies remotely > > > if a remote path is given and not present in the cache (if i'm not > > > wrong and if they honor their doc). > > > > > > May be those variables could be of use? but may be I misunderstood the > > > problem. > > > > > > HTH, > > > Rgs, > > > Eric. > > > > > > > > > On Fri, Sep 13, 2019 at 10:05 PM Evan Silberman <e...@jklol.net> wrote: > > >> > > >> Stuart Henderson <s...@spacehopper.org> wrote: > > >> > +MAKE_ENV += > > >> > GOPROXY=invalid://ports.should.not.fetch.at.buildtime/ > > >> > > >> Got sufficiently curious to check if the URI scheme example:// is > > >> reserved and lo and behold it is. Might as well use it here? > > >> > > >> https://tools.ietf.org/html/rfc7595#page-14 > > >> > > >> Evan Silberman > > >> > > > > > >
