go: cmd/go: go get -u in module mode can fail and produce output that's not easy to diagnose

This issue is related to issue https://github.com/golang/lint/issues/436. That issue is about a problem in the lint repository. This issue is about a problem in cmd/go.

We added a go.mod file to the lint repository in CL 162913 today, following the process described in https://golang.org/issue/28136#issuecomment-462971974. We quickly learned via an issue report at https://github.com/golang/lint/issues/436 that doing so caused go get -u golang.org/x/lint to begin to fail when in module mode. Previously, go get -u golang.org/x/lint succeeded in module mode. go get golang.org/x/lint, without -u continues to work.

The go.mod file specifies the module path to be “golang.org/x/lint”, which matches the import path comment of the lint package. The import path comment means no current Go package can import the lint package at an import path other than golang.org/x/lint successfully. However, older versions of modules can and do.

As @thepudds shared in https://github.com/golang/lint/issues/436#issuecomment-468110230, there is an old module version that refers to lint repository via an incorrect github.com/golang/lint path:

google.golang.org/grpc@v1.16.0 - https://github.com/grpc/grpc-go/blob/v1.16.0/go.mod#L7

That latest version of the github.com/openzipkin/zipkin-go module is currently v0.1.5. That version requires the bad old grpc version:

https://github.com/openzipkin/zipkin-go/blob/v0.1.5/go.mod#L27

What ends up happening is that installing the lint module ends up pulling in many modules incidentally (x/tools module -> appengine module -> … -> x/build module -> …). Some module ends up pulling in the latest module of zipkin-go, which in turn pulls in the bad grpc version. Since -u flag is used, go get fetches the latest pseudo-version of the github.com/golang/lint module, which is now v0.0.0-20190227174305-5b3e6a55c961 and includes a go.mod file stating the module path to be golang.org/x/lint, causing the error:

go: github.com/golang/lint@v0.0.0-20190227174305-5b3e6a55c961: parsing go.mod: unexpected module path "golang.org/x/lint"

There are a few issues here that should be investigated. For example, the error message from go get -u can be improved to make diagnosing the situation better. Perhaps more.

/cc @bcmills @jayconrod @matloob @thepudds

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 17 (17 by maintainers)

Commits related to this issue

Fix golint installation, version tools golint changed its import path [1], and that along with the advent of modules caused fallout [2, 3] that broke the `go get -u` installation in our makefile/CI b... — committed to go-kafka/connect by ches 5 years ago

Most upvoted comments

Some module ends up pulling in the latest module of zipkin-go, which in turn pulls in the bad grpc version.

One workaround might be to explicitly upgrade google.golang.org/grpc above v1.16.0 in the requirements of golang.org/x/lint. That way, when someone runs go get -u, the invalid path is no longer in the transitive import graph and its module should not be included.

bcmills on Feb 28, 2019

the error message from go get -u can be improved to make diagnosing the situation better.

That’s #28489.

bcmills on Feb 28, 2019

Haven’t looked at this carefully, but the resty mismatch might now be coming in via grpc-gateway:

github.com/grpc-ecosystem/grpc-gateway/@v/v1.8.0.mod:   github.com/go-resty/resty v1.9.0
github.com/grpc-ecosystem/grpc-gateway/@v/v1.8.0.mod:replace github.com/go-resty/resty => gopkg.in/resty.v1 v1.9.0

It looks like https://github.com/grpc-ecosystem/grpc-gateway released v1.8.0 about 5 hours ago. It looks like that might be the first release with go.mod. Note that it uses github.com/go-resty/resty in the require section of its go.mod, but has a replace github.com/go-resty/resty => gopkg.in/resty.v1 v1.9.0.

thepudds on Mar 1, 2019

@dmitshur FYI, re-running the replace-based workaround that worked for me two days ago in https://github.com/golang/lint/issues/436#issuecomment-468126102 now fails with:

go: github.com/go-resty/resty@v1.9.0: parsing go.mod: unexpected module path "gopkg.in/resty.v1"

(Perhaps better for this comment to be on golang/lint#436, but adding it here because golang/lint#436 is now a fairly high volume issue).

Commands

mkdir /tmp/scratchpad/lint-test-workaround-rerun-1
cd /tmp/scratchpad/lint-test-workaround-rerun-1
export GOPATH=/tmp/scratchpad/gopath-for-lint-workaround-rerun-1
go mod init tempmod
echo 'replace google.golang.org/grpc => google.golang.org/grpc v1.19.0' >> go.mod
echo 'replace github.com/openzipkin/zipkin-go => github.com/openzipkin/zipkin-go b722d64 // current master' >> go.mod
go get -u golang.org/x/lint

thepudds on Mar 1, 2019

@dmitshur if you tell me it is the right CL, I would believe you. 😉

It does seem to be the one: https://go-review.googlesource.com/c/tools/+/160837/2/go.mod

thepudds on Feb 28, 2019

@dmitshur yet another possible solution might be merging https://golang.org/cl/160837, but (a) I haven’t looked closely enough to know if that is true, and (b) that might be more work than other possible solutions already on the table.

edit: sorry, scratch that, I think that is actually not the right CL… but I had thought there was another pending CL that would further cut down on more of the golang.org/x/... dependencies, but not sure.

thepudds on Feb 28, 2019