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: prefer to report mismatched module paths over mismatched major versions #34432

Open
brenol opened this issue Sep 20, 2019 · 14 comments

Comments

@brenol
Copy link

commented Sep 20, 2019

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.

@brenol

This comment has been minimized.

Copy link
Author

commented Sep 20, 2019

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

This comment has been minimized.

Copy link
Member

commented Sep 20, 2019

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

This comment has been minimized.

Copy link
Member

commented Sep 20, 2019

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:

  1. That the module path in general does not match the requested module path.
  2. 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.

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

This comment has been minimized.

Copy link
Member

commented Sep 20, 2019

@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

This comment has been minimized.

Copy link
Author

commented Sep 20, 2019

@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

This comment has been minimized.

Copy link
Author

commented Sep 20, 2019

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

This comment has been minimized.

Copy link
Member

commented Sep 20, 2019

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

This comment has been minimized.

Copy link
Author

commented Sep 20, 2019

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

This comment has been minimized.

Copy link
Member

commented Sep 20, 2019

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

This comment has been minimized.

Copy link
Member

commented Sep 20, 2019

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

This comment has been minimized.

Copy link
Author

commented Sep 20, 2019

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

This comment has been minimized.

Copy link
Member

commented Sep 20, 2019

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

This comment has been minimized.

Copy link
Member

commented Sep 20, 2019

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.

@bcmills bcmills closed this Sep 20, 2019
@thepudds

This comment has been minimized.

Copy link

commented Sep 21, 2019

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

@bcmills 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 bcmills reopened this Sep 23, 2019
@rsc rsc modified the milestones: Go1.14, Backlog Oct 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.