Skip to content
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 module warning about non-....v0 versions? #30636

Open
tych0 opened this Issue Mar 6, 2019 · 4 comments

Comments

Projects
None yet
4 participants
@tych0
Copy link

tych0 commented Mar 6, 2019

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

@tych0 tych0 referenced this issue Mar 6, 2019

Open

Go modules bug #35

@heschik heschik added the modules label Mar 6, 2019

@jayconrod jayconrod changed the title go module warning about non-....v0 versions? cmd/go: go module warning about non-....v0 versions? Mar 6, 2019

@bcmills bcmills added this to the Go1.13 milestone Mar 6, 2019

@bcmills

This comment has been minimized.

Copy link
Member

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

@tych0

This comment has been minimized.

Copy link
Author

tych0 commented 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

This comment has been minimized.

Copy link
Member

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

@tych0

This comment has been minimized.

Copy link
Author

tych0 commented 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.

tych0 added a commit to tych0/pb that referenced this issue Mar 7, 2019

don't use gopkgin
The repositories github.com/mattn/go-colorable and
github.com/mattn/go-isatty have moved to using go modules; using gopkg.in
to import them breaks:

golang/go#30636

Let's use the real URLs with hashes.

Signed-off-by: Tycho Andersen <tycho@tycho.ws>

tych0 added a commit to anuvu/atomfs that referenced this issue Mar 7, 2019

move deps back before go modules
See golang/go#30636

Signed-off-by: Tycho Andersen <tycho@tycho.ws>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.