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

[tych0]

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

[bcmills]

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

[tych0]

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]

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.

[tych0]

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.

[bcmills]

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

[michaeljs1990]

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

[seankhliao]

Seems a lot less relevant these days now that ~everything has a go.mod.