cmd/go: prefer to report mismatched module paths over mismatched major versions #34432

brenol · 2019-09-20T14:55:51Z

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

$ go version
go version go1.13 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (`go env`)?

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/brenol/.cache/go-build"
GOENV="/home/brenol/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY="bitbucket.org"
GONOSUMDB="bitbucket.org"
GOOS="linux"
GOPATH="/home/brenol/goworkspace"
GOPRIVATE="bitbucket.org"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/brenol/goworkspace/src/github.com/twitchscience/kinsumer/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build321165660=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Tried to run go mod tidy in github.com/twitchscience/kinsumer

What did you expect to see?

I expected it to report correctly that the project github.com/myesui/uuid is the one that uses gopkg.in/stretchr/testify.v1. However, it's reporting that twinj/uuid incorrectly is the one that is using.

What did you see instead?

go: finding gopkg.in/stretchr/testify.v1 v1.4.0
github.com/twitchscience/kinsumer imports
	github.com/twinj/uuid tested by
	github.com/twinj/uuid.test imports
	gopkg.in/stretchr/testify.v1/assert: cannot find module providing package gopkg.in/stretchr/testify.v1/assert

How the module looks like:

module github.com/twitchscience/kinsumer

go 1.13

require (
	github.com/aws/aws-sdk-go v1.24.2
	github.com/cactus/go-statsd-client/statsd v0.0.0-20190906215803-47b6058c80f5
	github.com/myesui/uuid v1.0.0 // indirect
	github.com/stretchr/testify v1.4.0
	github.com/twinj/uuid v1.0.0

	golang.org/x/net v0.0.0-20190918130420-a8b05e9114ab // indirect
	golang.org/x/sync v0.0.0-20190911185100-cd5d95a43a6e
)

The strangest thing is that I see no mention of myesui/uuid in the vendored directory.

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

brenol · 2019-09-20T14:57:33Z

While debugging this issue I also got this output, not sure on how I did that though:

go get gopkg.in/stretchr/testify.v1: gopkg.in/stretchr/testify.v1@v1.4.0: invalid version: go.mod has non-....v1 module path "github.com/stretchr/testify" at revision v1.4.0

bcmills · 2019-09-20T15:32:08Z

The chain reported by the first error message looks accurate:

github.com/twitchscience/kinsumer imports github.com/twinj/uuid: link
tested by github.com/twinj/uuid.test imports gopkg.in/stretchr/testify.v1/assert: link
cannot find module providing package gopkg.in/stretchr/testify.v1/assert: link

That last error is because the module path declared by the go.mod file does not match the path by which the module was imported, a fact should have been reported earlier in the error output. Was it? (If not, that's a diagnostic bug we should fix.)

bcmills · 2019-09-20T15:33:46Z

go get gopkg.in/stretchr/testify.v1: gopkg.in/stretchr/testify.v1@v1.4.0: invalid version: go.mod has non-....v1 module path "github.com/stretchr/testify" at revision v1.4.0

There are two possible errors the go command could have reported there:

That the module path in general does not match the requested module path.
That the major version of the module path does not match the major version implied by the gopkg.in URL.

Both are correct; (1) is probably clearer, but the go command ended up reporting (2) instead. We should fix that.

bcmills · 2019-09-20T15:46:32Z

@brenol, could you give some more detail as to why you expected to see github.com/myesui/uuid instead of github.com/twinj/uuid?

brenol · 2019-09-20T16:58:07Z

@brenol, could you give some more detail as to why you expected to see github.com/myesui/uuid instead of github.com/twinj/uuid?

I actually tried to mean that I did not expect to see github.com/myesui/uuid anywhere in the go.mod file, as I don't see any references of it in github.com/twinj/uuid source code.

brenol · 2019-09-20T17:08:04Z

The chain reported by the first error message looks accurate:

github.com/twitchscience/kinsumer imports github.com/twinj/uuid: link

tested by github.com/twinj/uuid.test imports gopkg.in/stretchr/testify.v1/assert: link

cannot find module providing package gopkg.in/stretchr/testify.v1/assert: link

That last error is because the module path declared by the go.mod file does not match the path by which the module was imported, a fact should have been reported earlier in the error output. Was it? (If not, that's a diagnostic bug we should fix.)

About this one, I did not see it report anywhere in the go mod tidy command, neither in the go build/go test etc.

One more thing: I feel like go mod vendor should checkout to the tag (or something like this? I'm not sure) that is actually being used. While debugging, I was looking at the go mod vendor to search for github.com/myesui/uuid but as it was nowhere to be found, I misunderstood the problem completely -- it is because go mod vendor was bringing github.com/twinj/uuid and leaving it at the master branch (which is the reason why, in my last comment, I mentioned I said "I don't see any references of it in github.com/twinj/uuid source)

bcmills · 2019-09-20T17:12:56Z

go mod vendor should checkout to the tag (or something like this? I'm not sure) that is actually being used

go mod vendor is intended to copy in the source code from the exact version in use. If you are seeing otherwise, please file a separate issue with steps to reproduce it.

brenol · 2019-09-20T17:44:24Z

Sure, opened #34435. I don't want to make this issue a conversation, however, I have a few more questions:

I see no mention of gopkg.in in go mod graph. Is this expected?

$ go mod graph
github.com/twitchscience/kinsumer github.com/aws/aws-sdk-go@v1.24.2
github.com/twitchscience/kinsumer github.com/cactus/go-statsd-client/statsd@v0.0.0-20190906215803-47b6058c80f5
github.com/twitchscience/kinsumer github.com/myesui/uuid@v1.0.0
github.com/twitchscience/kinsumer github.com/stretchr/testify@v1.4.0
github.com/twitchscience/kinsumer github.com/twinj/uuid@v1.0.0
github.com/twitchscience/kinsumer golang.org/x/net@v0.0.0-20190918130420-a8b05e9114ab
github.com/twitchscience/kinsumer golang.org/x/sync@v0.0.0-20190911185100-cd5d95a43a6e
github.com/aws/aws-sdk-go@v1.24.2 github.com/jmespath/go-jmespath@v0.0.0-20180206201540-c2b33e8439af
golang.org/x/net@v0.0.0-20190918130420-a8b05e9114ab golang.org/x/crypto@v0.0.0-20190308221718-c2843e01d9a2
golang.org/x/net@v0.0.0-20190918130420-a8b05e9114ab golang.org/x/sys@v0.0.0-20190215142949-d0b11bdaac8a
golang.org/x/net@v0.0.0-20190918130420-a8b05e9114ab golang.org/x/text@v0.3.0
github.com/stretchr/testify@v1.4.0 github.com/davecgh/go-spew@v1.1.0
github.com/stretchr/testify@v1.4.0 github.com/pmezard/go-difflib@v1.0.0
github.com/stretchr/testify@v1.4.0 github.com/stretchr/objx@v0.1.0
github.com/stretchr/testify@v1.4.0 gopkg.in/yaml.v2@v2.2.2
golang.org/x/crypto@v0.0.0-20190308221718-c2843e01d9a2 golang.org/x/sys@v0.0.0-20190215142949-d0b11bdaac8a
gopkg.in/yaml.v2@v2.2.2 gopkg.in/check.v1@v0.0.0-20161208181325-20d25e280405

The other question is if go mod why should output the same error as the go mod tidy:

$ go mod why github.com/myesui/uuid                                                                                                                                                             
go: finding gopkg.in/stretchr/testify.v1 v1.4.0
go: finding gopkg.in/stretchr/testify.v1 v1.4.0
github.com/twitchscience/kinsumer imports
	github.com/twinj/uuid tested by
	github.com/twinj/uuid.test imports
	gopkg.in/stretchr/testify.v1/assert: cannot find module providing package gopkg.in/stretchr/testify.v1/assert

bcmills · 2019-09-20T17:50:36Z

I see no mention of gopkg.in in go mod graph. Is this expected?

Check the last three lines. (You have two dependencies in gopkg.in.)

bcmills · 2019-09-20T17:52:47Z

The other question is if go mod why should output the same error as the go mod tidy:

go mod why should probably be more error-tolerant than it is, and probably should not try to resolve missing imports. (#26977 is somewhat related.)

brenol · 2019-09-20T17:57:35Z

I see no mention of gopkg.in in go mod graph. Is this expected?

Check the last three lines. (You have two dependencies in gopkg.in.)

Sorry, tried to mean that I see no mention of gopkg.in/stretchr/testify.v1. This is expected then, right?

About the go mod why, I see. Thank you.

bcmills · 2019-09-20T18:09:12Z

Yep, this is expected: the reason go mod graph isn't showing the dependency is because nothing ever resolves the import successfully, so the corresponding module never gets added to the module graph. (That was one reason we focused on the import-based diagnostics for 1.13.)

bcmills · 2019-09-20T18:10:27Z

I think the module resolution is working as designed here (and the go mod vendor issue is tracked separately).

I'm going to close this issue, but we'll certainly bear this report in mind when we're thinking about how to further improve the diagnostics.

thepudds · 2019-09-21T00:52:50Z

@bcmills

There are two possible errors the go command could have reported there:

That the module path in general does not match the requested module path.
That the major version of the module path does not match the major version implied by the gopkg.in URL.
Both are correct; (1) is probably clearer, but the go command ended up reporting (2) instead. We should fix that.

I’ve seen that trip other people up, and I agree with your assessment that 1 is clearer (significantly clearer, I think).

What do you think about perhaps re-opening this issue and using it to track that change? (Or maybe there’s already another issue, or maybe a new one should be opened…)

toothrot added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Sep 20, 2019

toothrot added this to the Go1.14 milestone Sep 20, 2019

bcmills added modules WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. and removed NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. labels Sep 20, 2019

bcmills closed this as completed Sep 20, 2019

bcmills mentioned this issue Sep 23, 2019

cmd/go: do not resolve missing imports in 'go mod why' #26977

Closed

bcmills changed the title ~~cmd/go: module: strange behavior with a forked project~~ cmd/go: prefer to report mismatched module paths over mismatched major versions Sep 23, 2019

bcmills reopened this Sep 23, 2019

bcmills added help wanted NeedsFix The path to resolution is known, but the work has not been done. and removed WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. labels Sep 23, 2019

bcmills mentioned this issue Sep 24, 2019

cmd/go: 'go get […]/v2@v2.X.Y' fails when the go.mod file for […]/v2 is at the repo root #34383

Closed

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

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cmd/go: prefer to report mismatched module paths over mismatched major versions #34432

cmd/go: prefer to report mismatched module paths over mismatched major versions #34432

brenol commented Sep 20, 2019 •

edited

brenol commented Sep 20, 2019

bcmills commented Sep 20, 2019 •

edited

bcmills commented Sep 20, 2019

bcmills commented Sep 20, 2019

brenol commented Sep 20, 2019

brenol commented Sep 20, 2019 •

edited

bcmills commented Sep 20, 2019 •

edited

brenol commented Sep 20, 2019

bcmills commented Sep 20, 2019

bcmills commented Sep 20, 2019

brenol commented Sep 20, 2019

bcmills commented Sep 20, 2019

bcmills commented Sep 20, 2019

thepudds commented Sep 21, 2019

cmd/go: prefer to report mismatched module paths over mismatched major versions #34432

cmd/go: prefer to report mismatched module paths over mismatched major versions #34432

Comments

brenol commented Sep 20, 2019 • edited

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

Does this issue reproduce with the latest release?

What operating system and processor architecture are you using (go env)?

What did you do?

What did you expect to see?

What did you see instead?

brenol commented Sep 20, 2019

bcmills commented Sep 20, 2019 • edited

bcmills commented Sep 20, 2019

bcmills commented Sep 20, 2019

brenol commented Sep 20, 2019

brenol commented Sep 20, 2019 • edited

bcmills commented Sep 20, 2019 • edited

brenol commented Sep 20, 2019

bcmills commented Sep 20, 2019

bcmills commented Sep 20, 2019

brenol commented Sep 20, 2019

bcmills commented Sep 20, 2019

bcmills commented Sep 20, 2019

thepudds commented Sep 21, 2019

brenol commented Sep 20, 2019 •

edited

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

What operating system and processor architecture are you using (`go env`)?

bcmills commented Sep 20, 2019 •

edited

brenol commented Sep 20, 2019 •

edited

bcmills commented Sep 20, 2019 •

edited