Skip to content

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

Not planned
@tych0

Description

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

Activity

changed the title [-]go module warning about non-....v0 versions?[/-] [+]cmd/go: go module warning about non-....v0 versions?[/+] on Mar 6, 2019
added
NeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.
on Mar 6, 2019
added this to the Go1.13 milestone on Mar 6, 2019
bcmills

bcmills commented on Mar 6, 2019

@bcmills
Contributor

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

tych0 commented on Mar 6, 2019

@tych0
Author

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

bcmills commented on Mar 6, 2019

@bcmills
Contributor

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

tych0 commented on Mar 6, 2019

@tych0
Author

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.

added a commit that references this issue on Mar 7, 2019
added a commit that references this issue on Mar 7, 2019
bcmills

bcmills commented on Mar 28, 2019

@bcmills
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    GoCommandcmd/goNeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.modules

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @rsc@jayconrod@andybons@tych0@michaeljs1990

        Issue actions

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