cmd/go: skip checking of go-import meta tags if replace exists for custom domain

[myitcv]

Please answer these questions before submitting your issue. Thanks!

What did you do?

At the time of writing, honnef.co is down/returning 50X errors.

So I tried to side-step this by adding a number of replace directive to the Github VCSs where the respective modules map.

e.g.

replace (
        honnef.co/js/dom => github.com/dominikh/go-js-dom v0.0.0-20180323154144-6da835bec70f
        honnef.co/go/js/util => github.com/dominikh/go-js-util v0.0.0-20150216223935-96b8dd9d1621
        honnef.co/go/js/xhr => github.com/dominikh/go-js-xhr v0.0.0-20150307031022-00e3346113ae
)

What did you expect to see?

I'd hoped to see that cmd/go did not try and hit honnef.co with URLs like https://honnef.co/go/js/dom?go-get=1 in order to determine the module root.

What did you see instead?

go: honnef.co/go/js/[email protected]: unrecognized import path "honnef.co/go/js/dom" (parse https://honnef.co/go/js/dom?go-get=1: no go-import meta tags ())

Is it reasonable to assume that if I have a replace directive path that matches a require that there is no module root checking required? Custom domain or otherwise I guess (although in this case it is a custom domain)?

I seem to remember some discussion from Russ about this in an issue/CL, but might be mistaken in that.

Does this issue reproduce with the latest release (go1.10.3)?

n/a: testing with tip

System details

go version devel +6b9c782f9f Wed Aug 1 00:57:00 2018 +0000 linux/amd64
GOARCH="amd64"
GOBIN="/home/myitcv/.mountpoints/x/src/myitcv.io/.bin"
GOCACHE="/home/myitcv/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/myitcv/.mountpoints/x"
GOPROXY=""
GORACE=""
GOROOT="/home/myitcv/gos"
GOTMPDIR=""
GOTOOLDIR="/home/myitcv/gos/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/myitcv/.mountpoints/x/src/myitcv.io/go.mod"
GOROOT/bin/go version: go version devel +6b9c782f9f Wed Aug 1 00:57:00 2018 +0000 linux/amd64
GOROOT/bin/go tool compile -V: compile version devel +6b9c782f9f Wed Aug 1 00:57:00 2018 +0000
uname -sr: Linux 4.15.0-29-generic
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.1 LTS
Release:	18.04
Codename:	bionic
/lib/x86_64-linux-gnu/libc.so.6: GNU C Library (Ubuntu GLIBC 2.27-3ubuntu1) stable release version 2.27.

/cc @rsc @bcmills

[bcmills]

Is it reasonable to assume that if I have a replace directive path that matches a require that there is no module root checking required?

Yes, but we still need to decide what version it is that we're replacing: if you require the current module from outside, it will still pick up a requirement at the original honnef.co path and need some version to run MVS on.

Did you specify a version to be replaced in the go.mod file? (Perhaps v0.0.0?)

Perhaps we should assume pseudo-version vM.0.0-00000000000000-000000000000 when we try to look up versions for replaced modules, but it's a little odd to automatically add a requirement on a version that doesn't actually exist.

[myitcv]

I should really have provided more context in my go.mod, apologies. Here's a slimmed down version, with master as the replacement "version" (i.e. this is pre me running the go command where that would get resolved):

module myitcv.io

require (
        honnef.co/go/js/dom v0.0.0-20180323154144-6da835bec70f
        honnef.co/go/js/util v0.0.0-20150216223935-96b8dd9d1621 // indirect
        honnef.co/go/js/xhr v0.0.0-20150307031022-00e3346113ae
)

replace (
        honnef.co/js/dom => github.com/dominikh/go-js-dom master
        honnef.co/go/js/util => github.com/dominikh/go-js-util master
        honnef.co/go/js/xhr => github.com/dominikh/go-js-xhr master
)

The versions in the require directives are those that previously successfully resolved (unsurprisingly they match the commits in the description of this issue). But, and I think this is the point you are hinting at, it could equally be that these require directives did not previously exist.

As you can see, I'm using version-agnostic replace directives.

Perhaps we should assume pseudo-version vM.0.0-00000000000000-000000000000 when we try to look up versions for replaced modules, but it's a little odd to automatically add a requirement on a version that doesn't actually exist.

Possibly in the case that a require directive (I keep using that word "directive", is it correct??) doesn't already exist.

[bcmills]

I seem to remember some discussion from Russ about this in an issue/CL

#26241?

[myitcv]

Ah, thank you. My searches were clearly not good enough. I'll close this issue in favour of #26241