go: cmd/go: one new module error is backwards, another seemed backwards
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.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 4
- Comments: 15 (9 by maintainers)
Commits related to 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-TryB... — committed to golang/go by bcmills 5 years ago
- [release-branch.go1.13] cmd/go/internal/modload: fix swapped paths in error message Cherry-picked from CL 191997. Updates #33879 Fixes #33885 Change-Id: Ifc91490b1cb791fdf5ffe69ef81c0ec0e6cbecc3 Re... — committed to golang/go by bcmills 5 years ago
- 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-TryB... — committed to tomocy/go by bcmills 5 years ago
- 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-TryB... — committed to t4n6a1ka/go by bcmills 5 years ago
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 ingo.mod
and re-releasing it.For reference, as far as we can tell, we’ve added everything needed here:
https://github.com/segmentio/stats/commit/6ed1dc36a432477e7a8c5105ac95ddd24806f223
However, trying to get it from a brand new module (and a clean mod cache):
Maybe related: https://github.com/golang/go/issues/34383
It’s not something that you set per se. It’s something which is required as part of the module spec.
https://github.com/golang/go/wiki/Modules#faqs--semantic-import-versioning
It’s certainly not my favorite feature of modules, but perhaps it will grow on me.
For this one, you might be missing the trailing
v2
suffix in the get command:(but I still think this is a usability problem nonetheless)
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 frommodule.MatchPathMajor
.)🤦♂️