cmd/go: one new module error is backwards, another seemed backwards #33879

thepudds · 2019-08-27T18:27:04Z

What version of Go are you using (`go version`)?

go1.13rc1

Does this issue reproduce with the latest release?

Not with Go 1.12, but yes with Go 1.13 rc1.

Issue 1

I think this new Go 1.13 error message is incorrectly swapping the two module paths in the final two lines of the error message:

        github.com/Sirupsen/logrus: github.com/Sirupsen/logrus@v1.4.2: parsing go.mod:
        module declares its path as: github.com/Sirupsen/logrus
                but was required as: github.com/sirupsen/logrus

Given the v1.4.2 version of that module declares its path as github.com/sirupsen/logrus, I think the correct form of the error would be:

        github.com/Sirupsen/logrus: github.com/Sirupsen/logrus@v1.4.2: parsing go.mod:
        module declares its path as: github.com/sirupsen/logrus
                but was required as: github.com/Sirupsen/logrus

Example from scratch:

$ cd $(mktemp -d)
$ go1.13rc1  mod init tempmod
$ cat <<EOF > main.go
package tempmod
import _ "github.com/docker/libcompose/docker"
EOF

$ go1.13rc1 build
[...]
go: tempmod imports
        github.com/docker/libcompose/docker imports
        github.com/Sirupsen/logrus: github.com/Sirupsen/logrus@v1.4.2: parsing go.mod:
        module declares its path as: github.com/Sirupsen/logrus
                but was required as: github.com/sirupsen/logrus

Issue 2

When I first saw this next error message in the wild, at first I thought it was backwards, but later concluded it was just potentially ambiguous (I think?):

$ go1.13rc1 get github.com/iiinsomnia/yiigo@v3.0.0
go: finding github.com v3.0.0
go: finding github.com/iiinsomnia v3.0.0
go: finding github.com/iiinsomnia/yiigo v3.0.0
go: finding github.com/iiinsomnia/yiigo v3.0.0
go get github.com/iiinsomnia/yiigo@v3.0.0: github.com/iiinsomnia/yiigo@v3.0.0: 
 invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v3

In particular, it is not immediately clear which major version should be v0 or v1, not v3 -- the major version after the @, or the major version in the module path on the module line in the go.mod. Because it leads off with module contains a go.mod file immediately before talking about the problematic major version, it seems like it is suggesting the major version in the go.mod file should be v0 or v1 (which is not the correct resolution, and you can't even have a v0 or v1 in the module line for a go.mod unless it is a corner case like gopkg.in).

In this example, there is a go.mod at v3.0.0, but that go.mod is missing the required /v3 at the end of the module path on the module line. As it stands, I think the error message is trying to say it would be acceptable to have a @v0.x.x or @v1.x.x in the go get for that go.mod? But that was not the way it read at first read, and moreover, one could at least argue that is not the fundamental error, which is really that the major version after the @ does not agree with the (missing) major version in the module path on the module line (and depending on how you look at it, that the go get is also missing the /v3 before the @).

I have seen other people read this second error message backwards as well. (Side note: I'm not sure why it emits go: finding github.com/iiinsomnia/yiigo v3.0.0 twice).

Finally, sorry -- this probably should have been two separate issues.

CC @jayconrod @bcmills

The text was updated successfully, but these errors were encountered:

bcmills · 2019-08-27T19:10:12Z

🤦‍♂️

bcmills · 2019-08-27T20:00:18Z

I think I can justify cherry-picking the fix for the swapped error message into the 1.13 release, but I'm not so sure about the compatibility error.

(That should be […] text comes from module.MatchPathMajor.)

gopherbot · 2019-08-27T20:07:48Z

Change https://golang.org/cl/191997 mentions this issue: cmd/go/internal/modload: fix swapped paths in error message

Updates #33879 Change-Id: Ifc91490b1cb791fdf5ffe69ef81c0ec0e6cbecc3 Reviewed-on: https://go-review.googlesource.com/c/go/+/191997 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Alexander Rakoczy <alex@golang.org>

bcmills · 2019-08-27T20:37:38Z

@gopherbot, please backport to 1.13: we should at least fix the reversed error message.

gopherbot · 2019-08-27T20:37:45Z

Backport issue(s) opened: #33885 (for 1.13).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases.

gopherbot · 2019-08-27T20:40:27Z

Change https://golang.org/cl/191972 mentions this issue: [release-branch.go1.13] cmd/go/internal/modload: fix swapped paths in error message

… error message Cherry-picked from CL 191997. Updates #33879 Fixes #33885 Change-Id: Ifc91490b1cb791fdf5ffe69ef81c0ec0e6cbecc3 Reviewed-on: https://go-review.googlesource.com/c/go/+/191997 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Alexander Rakoczy <alex@golang.org> (cherry picked from commit 8f5353f) Reviewed-on: https://go-review.googlesource.com/c/go/+/191972 TryBot-Result: Gobot Gobot <gobot@golang.org>

Updates golang#33879 Change-Id: Ifc91490b1cb791fdf5ffe69ef81c0ec0e6cbecc3 Reviewed-on: https://go-review.googlesource.com/c/go/+/191997 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Alexander Rakoczy <alex@golang.org>

abraithwaite · 2019-09-23T23:03:04Z

I might not be the best to comment on this, but as it stands now, this error message is pretty hard to understand. It's unclear which action I should take as either a module maintainer or a module consumer what to do. In this case, I am both and still unsure what to do.

In our case, we're attempting to convert modules which already have been tagged past v2.* into the proper form: adding the suffix to the module name in go.mod and re-releasing it.

For reference, as far as we can tell, we've added everything needed here:

segmentio/stats@6ed1dc3

However, trying to get it from a brand new module (and a clean mod cache):

16:01:10 $ GO111MODULE=on GOPROXY=direct go get github.com/segmentio/stats/v4@v4.5.0
go: extracting github.com/segmentio/stats/v4 v4.5.0
go: finding github.com/segmentio/stats v4.5.0
go get github.com/segmentio/stats/v4@v4.5.0: github.com/segmentio/stats@v4.5.0: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v4

Maybe related: #34383

abraithwaite · 2019-09-23T23:50:35Z

For my own sanity, I checked to see if this issue could be reproduced for modules which have a "correct" git history. that is: the go.mod package directive has been updated to include the vX suffix throughout this history, for tags that reference a major version. It does still trigger the bug.

This repo has the correct v2 suffix in the go.mod file for the v2.0.0 and v2.1.0 tags and it still triggers this issue.

imissyouso · 2019-09-24T08:30:50Z

hi. I have similar issue with my repository https://github.com/imissyouso/textmagic-rest-go/tree/v2.0.343

$ go get github.com/imissyouso/textmagic-rest-go@v2.0.343: github.com/imissyouso/textmagic-rest-go@v2.0.343: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v2

abraithwaite · 2019-09-24T14:25:08Z

hi. I have similar issue with my repository https://github.com/imissyouso/textmagic-rest-go/tree/v2.0.343

For this one, you might be missing the trailing v2 suffix in the get command:

github.com/imissyouso/textmagic-rest-go@v2.0.343
should be
github.com/imissyouso/textmagic-rest-go/v2@v2.0.343

(but I still think this is a usability problem nonetheless)

crazybber · 2019-10-23T08:46:05Z

issue still in go1.13.3.
try cmd in https://github.com/Microsoft/vscode-go/wiki/Go-tools-that-the-Go-extension-depends-on

go get -u -v github.com/ramya-rao-a/go-outline
.......
go get -u -v golang.org/x/lint/golint
.....

gometalinter --install

work fine in win cmd .
in bash/powershell/pwsh.

it will reproduce the above issue1 .

go: finding github.com/golang/lint latest
go: github.com/golang/lint/golint: github.com/golang/lint@v0.0.0-20190930215403-16217165b5de: parsing go.mod:  
        module declares its path as: golang.org/x/lint
                but was required as: github.com/golang/lint
WARNING: failed to install one or more linters: exit status 1 (installing individually)
go: finding github.com/golang/lint latest
go: github.com/golang/lint/golint: github.com/golang/lint@v0.0.0-20190930215403-16217165b5de: parsing go.mod:  
        module declares its path as: golang.org/x/lint
                but was required as: github.com/golang/lint
WARNING: failed to install github.com/golang/lint/golint: exit status 1

same time, one more issue:

go get -v -u github.com/uudashr/gopkgs/cmd/gopkgs

work fine in win cmd .
in Bash/powershell/pwsh.
it will produce :

go: finding github.com/uudashr/gopkgs/cmd/gopkgs latest
go: finding github.com/uudashr/gopkgs/cmd latest
go get: github.com/uudashr/gopkgs/cmd/gopkgs@v0.0.0-20191022034909-9ad6b82ad5c3 requires
        github.com/uudashr/gopkgs/v2@v2.0.3: reading github.com/uudashr/gopkgs/go.mod at revision v2.0.3: unknown revision v2.0.3

ref : https://github.com/uudashr/gopkgs

bcmills · 2019-10-23T13:52:40Z

@crazybber, both of those error messages are correct as far as I can tell. The module declares its path error correctly shows golang.org/x/lint per its go.mod file, and there really is no v2.0.3 tag in github.com/uudashr/gopkgs at the moment.

bcmills · 2019-10-23T13:53:34Z

I'm going to close this issue to reduce confusion. @thepudds, feel free to file a separate issue for the second error message.

thepudds changed the title ~~cmd/go: one new module error message is backwards, another initially seemed backwards~~ cmd/go: one new module error is backwards, another seemed backwards Aug 27, 2019

thepudds added the modules label Aug 27, 2019

bcmills self-assigned this Aug 27, 2019

bcmills added this to the Go1.14 milestone Aug 27, 2019

bcmills added the NeedsFix The path to resolution is known, but the work has not been done. label Aug 27, 2019

gopherbot mentioned this issue Aug 27, 2019

cmd/go: one new module error is backwards, another seemed backwards [1.13 backport] #33885

Closed

This comment has been minimized.

Sign in to view

rsc modified the milestones: Go1.14, Backlog Oct 9, 2019

bcmills closed this as completed Oct 23, 2019

torbenschinke mentioned this issue Dec 6, 2019

Can not compile packages with v2 worldiety/goup#4

Closed

golang locked and limited conversation to collaborators Oct 22, 2020

gopherbot added the FrozenDueToAge label Oct 22, 2020

rsc unassigned bcmills Jun 23, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cmd/go: one new module error is backwards, another seemed backwards #33879

cmd/go: one new module error is backwards, another seemed backwards #33879

thepudds commented Aug 27, 2019 •

edited

bcmills commented Aug 27, 2019

bcmills commented Aug 27, 2019

gopherbot commented Aug 27, 2019

bcmills commented Aug 27, 2019

gopherbot commented Aug 27, 2019

gopherbot commented Aug 27, 2019

abraithwaite commented Sep 23, 2019 •

edited

abraithwaite commented Sep 23, 2019

imissyouso commented Sep 24, 2019

abraithwaite commented Sep 24, 2019

This comment has been minimized.

This comment has been minimized.

crazybber commented Oct 23, 2019 •

edited

bcmills commented Oct 23, 2019

bcmills commented Oct 23, 2019

cmd/go: one new module error is backwards, another seemed backwards #33879

cmd/go: one new module error is backwards, another seemed backwards #33879

Comments

thepudds commented Aug 27, 2019 • edited

What version of Go are you using (go version)?

Does this issue reproduce with the latest release?

Issue 1

Issue 2

bcmills commented Aug 27, 2019

bcmills commented Aug 27, 2019

gopherbot commented Aug 27, 2019

bcmills commented Aug 27, 2019

gopherbot commented Aug 27, 2019

gopherbot commented Aug 27, 2019

abraithwaite commented Sep 23, 2019 • edited

abraithwaite commented Sep 23, 2019

imissyouso commented Sep 24, 2019

abraithwaite commented Sep 24, 2019

This comment has been minimized.

This comment has been minimized.

crazybber commented Oct 23, 2019 • edited

bcmills commented Oct 23, 2019

bcmills commented Oct 23, 2019

thepudds commented Aug 27, 2019 •

edited

What version of Go are you using (`go version`)?

abraithwaite commented Sep 23, 2019 •

edited

crazybber commented Oct 23, 2019 •

edited