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 · 6 comments
Open

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

tych0 opened this issue Mar 6, 2019 · 6 comments
Labels
GoCommand cmd/go modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

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

@heschi heschi 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
@jayconrod jayconrod added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. GoCommand cmd/go labels Mar 6, 2019
@bcmills bcmills added this to the Go1.13 milestone Mar 6, 2019
@bcmills
Copy link
Contributor

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
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
Copy link
Contributor

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
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
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
See golang/go#30636

Signed-off-by: Tycho Andersen <tycho@tycho.ws>
@bcmills
Copy link
Contributor

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

@michaeljs1990
Copy link

michaeljs1990 commented Jun 13, 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
GoCommand cmd/go modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

7 participants