cmd/go: error loading subpackage with pathMajor suffix

[urandom2]

What version of Go are you using (go version)?

$ go version
go version go1.12.4 linux/amd64

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/user/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/user/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/lib/go"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/tmp/test/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build918357550=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Tried to fetch a poorly named subpackage at v1.2.0:

go get github.com/arnottcr/ec624df40c51964d7facff2c86bc6cd4/sub/v4

What did you expect to see?

Successfully fetch the v1.2.0 module:

go: finding github.com/arnottcr/ec624df40c51964d7facff2c86bc6cd4 v1.2.0

What did you see instead?

go: finding github.com/arnottcr/ec624df40c51964d7facff2c86bc6cd4/v2/sub/v3 v3.0.0
go: finding github.com/arnottcr/ec624df40c51964d7facff2c86bc6cd4/sub/v3 v3.0.0
go: finding github.com/arnottcr/ec624df40c51964d7facff2c86bc6cd4/v2 v2.0.0
go: finding github.com/arnottcr/ec624df40c51964d7facff2c86bc6cd4 v1.2.0
go: finding github.com/arnottcr/ec624df40c51964d7facff2c86bc6cd4/sub/v4 v4.0.0
go: github.com/arnottcr/ec624df40c51964d7facff2c86bc6cd4/sub/v4@v4.0.0: missing github.com/arnottcr/ec624df40c51964d7facff2c86bc6cd4/sub/go.mod and .../v4/go.mod at revision sub/v4.0.0
go: error loading module requirements

While I concede that this repo is built to test edge cases and collisions in module resolution, there is only one correct resolution for sub/v4 => github.com/arnottcr/ec624df40c51964d7facff2c86bc6cd4@v1.2.0/sub/v4. Is this expected, since I know many google APIs use vN packages to track the API version, not the library version.

Also, this resolution scheme pulls in a number of versions that I would not expect (v2/sub/v3.0.0, etc.). Should it not check two, then stop:

• github.com/arnottcr/ec624df40c51964d7facff2c86bc6cd4/sub/v4 v4.x.x
• github.com/arnottcr/ec624df40c51964d7facff2c86bc6cd4 v1.x.x

[thepudds]

I know many google APIs use vN packages to track the API version, not the library version.

I believe in general that is usually not a major issue in practice. I believe the way it is supposed to work in terms of restrictions around packages named /v2 or /vN is briefly described in #28435 (comment) and #28435 (comment). A repo named github.com/my/v4 with a module named github.com/my/v4 is problematic, for example, but a package named github.com/some/repo/pkg/v4 living inside a module named github.com/some/repo should not be a problem, at least in theory.

That said, this is a complex example, so maybe what you are seeing is a bug, or maybe it is a correct but non-obvious result (including because the repo itself has a fairly complex setup with a complex history).

There is a sub/v4.0.0 tag at https://github.com/arnottcr/ec624df40c51964d7facff2c86bc6cd4/tree/sub/v4.0.0, but that has a /v2-based go.mod and only nests a /v4-based go.mod within a /v2 subdirectory, which might be the problem the error is complaining about.

Alternatively, perhaps the presence of
https://github.com/arnottcr/ec624df40c51964d7facff2c86bc6cd4/blob/v1.2.0/sub/v3/go.mod is causing it to look for github.com/arnottcr/ec624df40c51964d7facff2c86bc6cd4/sub/v4/go.mod when you do go get github.com/arnottcr/ec624df40c51964d7facff2c86bc6cd4/sub/v4, but that is just a shot in the dark.

On the other hand, this seems to work:

go get github.com/arnottcr/ec624df40c51964d7facff2c86bc6cd4/sub/v4@v1.2.0

[thepudds]

Some possibly related discussion in #30850, #30851.

[julieqiu]

/cc @bcmills @jayconrod

[bcmills]

This looks like an easy fix, and is closely related to the Query refactoring I did for proxy fallback.

[bcmills]

I take that back. It's not an easy fix because there actually is a sub/v4.0.0 tag on the repo, and it points to a commit that indeed lacks a go.mod file at either of the acceptable locations (sub/go.mod or sub/v4/go.mod). That causes the search to stop: the tag indicates that thing you've named on the command line should be interpreted as a module path, and there is no such module at that path.

We're not going to go out of our way to make go get resolve ambiguous queries against repos with adversarial tags. If you remove the misleading tag, you should find that sub/v4 resolves just fine; otherwise, please file a new issue with steps to reproduce against a more realistic repository.