Go: cmd/go: go module warning about non-....v0 versions?

Created on 6 Mar 2019 · 6Comments · Source: golang/go

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/[email protected]: 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).

GoCommand NeedsInvestigation modules

Source

tych0

Most helpful comment

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.

tych0 on 6 Mar 2019

👍5

All 6 comments

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 the go.mod file indicates that the github.com import path is canonical, not the gopkg.in one. See also #28489.)

bcmills on 6 Mar 2019

👎2

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?

tych0 on 6 Mar 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 the go.mod file for that dependency. It's not a good long-term solution, but might be enough for a temporary fix.

bcmills on 6 Mar 2019

👎1

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.

tych0 on 6 Mar 2019

👍5

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.)

bcmills on 28 Mar 2019

This is not ideal but a relatively painless workaround until the upstream fixes its imports is using replace. Something like the following can be used. Note that if you have dependencies that use both the replace must not use the same version between them. Would be nice if go mod had an alias keyword for cases like this that would just let you point gopkg.in to the new place that you expect them to be while people transition over.

replace gopkg.in/mattn/go-colorable.v0 => github.com/mattn/go-colorable v0.1.2
replace gopkg.in/mattn/go-isatty.v0 => github.com/mattn/go-isatty v0.0.7