Description
What version of Go are you using (go version)?
$ go version go version go1.17.2 darwin/arm64
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="" GOARCH="arm64" GOBIN="" GOCACHE="/Users/myusername/Library/Caches/go-build" GOENV="/Users/myusername/Library/Application Support/go/env" GOEXE="" GOEXPERIMENT="" GOFLAGS="" GOHOSTARCH="arm64" GOHOSTOS="darwin" GOINSECURE="" GOMODCACHE="/Users/myusername/go/pkg/mod" GONOPROXY="" GONOSUMDB="" GOOS="darwin" GOPATH="/Users/myusername/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/opt/homebrew/opt/go/libexec" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/opt/homebrew/opt/go/libexec/pkg/tool/darwin_arm64" GOVCS="" GOVERSION="go1.17.2" GCCGO="gccgo" AR="ar" CC="clang" CXX="clang++" CGO_ENABLED="1" GOMOD="/Users/myusername/Documents/gitroot/modimport/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 -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/2_/wb7qpk5n21l9yw2f1kj1_jj00000gn/T/go-build556537930=/tmp/go-build -gno-record-gcc-switches -fno-common"
What did you do?
I have two repositories, one library: https://github.com/shou1dwe/modoriginal with a go.mod like:
module my.com/modoriginal
go 1.17
Its go.mod contains a name different from its VCS location: my.com/modoriginal
When using this library from another repository https://github.com/shou1dwe/modimport
A replace is required in go.mod like below:
module github.com/shou1dwe/modimport
go 1.17
require my.com/modoriginal v1.0.0
replace my.com/modoriginal => github.com/shou1dwe/modoriginal v1.0.0
With this setup, go run main.go in modimport repository works fine, everything works.
Then my.com/modoriginal author decided to introduce a breaking change and follow this guide: https://go.dev/blog/v2-go-modules, but decided to go with "major versions on separate branches" approach. So now there is https://github.com/shou1dwe/modoriginal/tree/v2 and also tag v2.0.0 created from the latest commit on v2 branch.
And modimport tries to use the same approach to retrieve new v2 version of modoriginal
module github.com/shou1dwe/modimport
go 1.17
require my.com/modoriginal/v2 v2.0.0
replace my.com/modoriginal/v2 => github.com/shou1dwe/modoriginal v2.0.0
What did you expect to see?
go mod tidy in modimport should exit 0 and return
go run main.go in modimport should print prefix test
What did you see instead?
$ go mod tidy
go: errors parsing go.mod:
/Users/myuser/Documents/gitroot/modimport/go.mod:7: replace github.com/shou1dwe/modoriginal: version "v3.0.0" invalid: should be v0 or v1, not v3
$ go run main.go
go: errors parsing go.mod:
/Users/myuser/Documents/gitroot/modimport/go.mod:7: replace github.com/shou1dwe/modoriginal: version "v2.0.0" invalid: should be v0 or v1, not v2Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
Participants
Activity
bcmills commentedon Nov 8, 2021
The error message here is correct, if somewhat unclear (that's #41512). The
v2.0.0version implies that the module path has a/v2suffix, and the replacement needs to use that suffix too:[-]Replace a v2 mod where there isn't a v2 directory[/-][+]cmd/go: Replace a v2 mod where there isn't a v2 directory[/+]shou1dwe commentedon Nov 9, 2021
thanks, I can confirm that appending /v2 to right-hand side of the replace directive fixed the problem.
For me the confusing part is that I have been treating
github.com/shou1dwe/modoriginalin the above context a VCS location rather than a "module name" or "module path"; and modoriginl's go.mod says the module name ismy.com/modoriginal/v2.Apparently the major version suffix rule applies to both places.