-
Notifications
You must be signed in to change notification settings - Fork 17.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/go: 'go get' of module in GOPATH mode fails due to semantic version import #35630
Comments
The issue here seems to be that Minimal module compatibility means that in GOPATH mode (
So if the file To be compatible with GOPATH mode, As a local workaround, you can either check out a specific tag of Closing because this seems to be working as designed, and we probably won't change semantics of minimal module compatibility at this point. |
Got it, all of this makes sense -- in trying to figure out what was going on, the piece I was missing/didn't properly consider was the "go.mod" file not being on the main branch. Agree that, given all of this, this is working as intended. Thanks for the explanation! |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?Official golang:1.13.4 Docker image:
go env
OutputWhat did you do?
(or a simple
go get github.com/mholt/archiver
in a GOPATH with nogo.mod
)What did you expect to see?
Success:
github.com/mholt/archiver
and all of its dependencies should be fetched and exist in their proper locations within$GOPATH/src
What did you see instead?
Details
github.com/mholt/archiver was recently updated to use Go modules. As part of this upgrade, one of its dependencies was upgraded to use github.com/pierrec/lz4/v3, which is another module. This module is at
github.com/pierrec/lz4
(it does not explicitly create a "v3" directory).It appears that there are clients that use "go get" in GOPATH mode to populate their GOPATH with their dependencies to build their projects in CI (presumably they are not vendoring). In this mode, "go get" can no longer be used to properly populate the GOPATH.
Setting
GO111MODULE=on go get github.com/mholt/archiver
causes the "get" operation to succeed, but is not helpful since it does not actually populate the GOPATH.I believe that if the GOPATH were properly populated, the minimal module compatibility code would allow the project to build. However, there does not seem to be any way to use
go get
to populate the GOPATH properly in this scenario.The text was updated successfully, but these errors were encountered: