Not planned
Description
What version of Go are you using (go version
)?
go version go1.12 linux/amd64
What did you do?
Run go get -u in this repository: https://github.com/tych0/go-bug
$ go get -u
go: gopkg.in/mattn/go-colorable.v0@v0.1.1: go.mod has non-....v0 module path "github.com/mattn/go-colorable" at revision v0.1.1
go: error loading module requirements
What did you expect to see?
Success.
What did you see instead?
The indecipherable error above :).
In particular, the repo I'm actually having this problem in has go as an indirect dep (i.e. the line gopkg.in/mattn/go-colorable doesn't occur in go.mod at all). However, the error message is the same (it complains about go.mod, even though the line isn't in there at all).
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
[-]go module warning about non-....v0 versions?[/-][+]cmd/go: go module warning about non-....v0 versions?[/+]bcmills commentedon Mar 6, 2019
Just to be clear, the thing we can fix here is the error message, not the fact that the error exists.
(The
module
line in thego.mod
file indicates that thegithub.com
import path is canonical, not thegopkg.in
one. See also #28489.)tych0 commentedon Mar 6, 2019
So what's the workaround for those of us who are using packages with these kinds of
gopkg.in
imports? Just wait until upstream fixes their imports?bcmills commentedon Mar 6, 2019
Pretty much, yes. (Send PRs, and avoid dependencies that use the wrong upstream paths.)
You may also find that you can make things sort-of-work by running
go get -m gopkg.in/mattn/go-colorable.v0@$COMMIT
with a commit that predates the addition of thego.mod
file for that dependency. It's not a good long-term solution, but might be enough for a temporary fix.tych0 commentedon Mar 6, 2019
It would also be handy to print out which repo has the bad import. As it stands right now I have to clone all the deps and grep them all.
don't use gopkgin
move deps back before go modules
bcmills commentedon Mar 28, 2019
In #30831 we're considering some mechanism for modules to declare other aliases by which they were previously known. That seems like it could help with the
github.com
/gopkg.in
confusion in this case too.(But let's keep the discussion about renaming over there, and focus this issue on the inscrutable error message.)
15 remaining items