cmd/go: 'go get […]/v2@v2.X.Y' fails when the go.mod file for […]/v2 is at the repo root

[abraithwaite]

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

$ go version
go version go1.13 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
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/abraithwaite/.cache/go-build"
GOENV="/home/abraithwaite/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/abraithwaite/Projects/golang"
GOPRIVATE=""
GOPROXY="direct"
GOROOT="/usr/lib/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
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-build983177457=/tmp/go-build -gno-record-gcc-switches"

What did you do?

We were upgrading a library (github.com/segmentio/events) to match proper major version module semantics (we already had some v2 release tags from before modules), and we kept running into the following when trying to go get the module.

GO111MODULE=on GOPROXY=direct go get -u github.com/segmentio/events/v2@v2.3.2
go: finding github.com/segmentio/events v2.3.2
go get github.com/segmentio/events/v2@v2.3.2: github.com/segmentio/events@v2.3.2: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v2

What did you expect to see?

We expected to see the module fetched without an error.

What did you see instead?

GO111MODULE=on GOPROXY=direct go get -u github.com/segmentio/events/v2@v2.3.2
go: finding github.com/segmentio/events v2.3.2
go get github.com/segmentio/events/v2@v2.3.2: github.com/segmentio/events@v2.3.2: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v2

We're aware that the other v2 tags are invalid: that is they don't have a correct go.mod file.

When we remove the v2 branch from the repository, go get works again without issues. We're skipping the module proxy and doing this with a clean modules cache. We expect that the error is a bit more clear at the very least. At the best, it ignores the v2 branch entirely and just uses the tag specified.

We're leaving the v2 branch in tact for now so that others can test and debug this issue.

Also interestingly, doing go get without specifying the exact tag works fine:

16:58:46 $ GO111MODULE=on GOPROXY=direct go get -u github.com/segmentio/events/v2
go: finding golang.org/x/sys latest
16:59:14 $ cat go.mod
module github.com/segmentio/blah

go 1.13

require github.com/segmentio/events/v2 v2.3.2 // indirect

[abraithwaite]

Seeing a similar issue with our stats package:

https://gist.github.com/abraithwaite/15a0ffd0021b4539793bc0ceb1dc3bc1

[abraithwaite]

This repo can consistently break the command:
go get github.com/abraithwaite/broken/v2@v2.1.0

When the repo you run this from is lacking the broken module in it's go.mod, this results in:

16:37:38 $ GO111MODULE=on GOPROXY=direct go get 'github.com/abraithwaite/broken/v2@v2.1.0'
go: finding github.com/abraithwaite/broken v2.1.0
go: finding github.com/abraithwaite/broken/v2 v2.1.0
go: downloading github.com/abraithwaite/broken/v2 v2.1.0
go: extracting github.com/abraithwaite/broken/v2 v2.1.0
go get github.com/abraithwaite/broken/v2@v2.1.0: github.com/abraithwaite/broken@v2.1.0: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v2

It also fails to update the go.mod file with any version of the broken module whatsoever:

16:38:00 $ cat go.mod
module example.com/test

go 1.13

[abraithwaite]

For my own sanity, I checked to see if this issue could be reproduced for modules which have a "correct" git history. that is: the go.mod package directive has been updated to include the vX suffix throughout this history, for tags that reference a major version. It does still trigger the bug.

This repo has the correct v2 suffix in the go.mod file for the v2.0.0 and v2.1.0 tags and it still triggers this issue.

[bcmills]

@gopherbot, please backport to 1.13. This is a regression, and the workaround (editing the go.mod file instead of using go get) does not work for downgrading.

[gopherbot]

Backport issue(s) opened: #34497 (for 1.13).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases.

[bcmills]

This turns out to be closely related to #34432, in that we should notice the mismatched module path and treat that as a “not found” error rather than a hard error.

[abraithwaite]

This turns out to be closely related to #34432, in that we should notice the mismatched module path and treat that as a “not found” error rather than a hard error.

Ah, so it's looking for the subdirectory erroneously? None of these repos that I've created/used have a vX subdirectory in their tree. Only git tags.