x/build: update dependencies in go.mod

[dmitshur]

The latest version of the golang.org/x/build module requires some older dependencies. Doing go get -u -m inside it currently fails with:

$ go get -u -m
...
go: github.com/golang/lint@v0.0.0-20190313153728-d0100b6bd8b3: parsing go.mod: unexpected module path "golang.org/x/lint"
...
go get: error loading module requirements
$ echo $?
1

See golang/lint#436 (comment).

/cc @bcmills @matloob @broady

[dmitshur]

The build list of the latest version of the golang.org/x/build module includes the github.com/openzipkin/zipkin-go module at version v0.1.1:

$ go list -m all | grep zipkin
github.com/openzipkin/zipkin-go v0.1.1

That version is fine, but the the current latest version of github.com/openzipkin/zipkin-go module, v0.1.5, requires a bad version of grpc (see openzipkin/zipkin-go#114). I suspect when you do go get -u -m on x/build, it ends up trying to update the zipkin-go module to its latest version, which in turn brings in the bad grpc version and the incorrect github.com/golang/lint module that it requires.

I think that when zipkin-go makes a newer semver tag that includes the fix from openzipkin/zipkin-go#115 and in turn resolves openzipkin/zipkin-go#117, then this issue will get resolved too.

An alternative path to resolution here is to remove dependencies from x/build such that the zipkin-go module is no longer in the build list of x/build (but that's probably not easy to do).

This assumes that no modules in the build list explicitly require github.com/openzipkin/zipkin-go v0.1.5 or v0.1.4, the two bad versions (v0.1.3 and earlier are okay, they don't require a bad version of grpc). So far, I haven't seen either of those two versions explicitly required anywhere.

[dmitshur]

I'll send a CL to remove the indirect dependency on grpc v1.16.0, we want to remove that as soon as possible.

Then, this module requires the cloud.google.com/go module, which in turn currently requires golang.org/x/build as well (this is tracked in googleapis/google-cloud-go#1344).

So, to make progress, x/build should drop its indirect requirement on grpc v1.16.0. Then the cloud.google.com/go module needs to be updated either to latest x/build pseudo-commit (without grpc v1.16.0), or not to depend on it at all. After that, x/build can be updated to depend on the new cloud.google.com/go version.

[gopherbot]

Change https://golang.org/cl/167597 mentions this issue: go.mod: drop indirect requirement of bad grpc version

[jeanbza]

CL that bumps us to latest x/build: https://code-review.googlesource.com/c/gocloud/+/39010

Will tag that after it's in.

[dmitshur]

@jadekler I'm beginning to realize the process I described in #30833 (comment) may not work.

https://code-review.googlesource.com/c/gocloud/+/39010 updates to the latest x/build pseudo-version, but that pseudo-version still requires a previous version of cloud, which in turn requires more old things...

Maybe the way to solve this is for x/build to issue a new pseudo-version (a new commit) that preemptively updates to the upcoming cloud tag. Then that pseudo-version of x/build can be used in the upcoming cloud tagged release. Does that make sense?

E.g., I'm spotting github.com/golang/lint in go.sum of that CL, which makes me think this won't fix the problem fully.

[jeanbza]

Ack. I'm happy to try it if you'd like, or we can punt. I think that fixing the core issue - #30831 - is probably the only "sane" solution heh. :)

[dmitshur]

I think that fixing the core issue - #30831 - is probably the only "sane" solution heh. :)

Sure, but a fix for that is unlikely to land before Go 1.13, which is still some time off. It'll prevent this general problem from re-occurring, but I imagine we can resolve this specific instance related to x/lint well before then.

Ack. I'm happy to try it if you'd like, or we can punt.

I've realized that current go.mod of x/build requires cloud.google.com/go@v0.31.0, which did not yet have a go.mod file, and therefore doesn't require an older x/build version.

That means you should be okay to proceed with tagging CL https://code-review.googlesource.com/c/gocloud/+/39010 (commit googleapis/google-cloud-go@88dee6a) as v0.37.1, and it will be a helpful change towards resolving the go get -u issue affecting the cloud module.

After you do that, I think I'm finding a relatively short path to resolve the rest of the problem in the cloud module, but it can be a separate follow up. I'll talk more about that in googleapis/google-cloud-go#1359.

[jeanbza]

I've released 0.37.1. Is the next step to release a version of x/build which depends on something later than 0.31.0?

[dmitshur]

@thepudds Did you close this issue unintentionally?

It's not yet fully resolved; doing go get -u -m on the x/build module still produces an error.

@jadekler Thanks for the update!

I don't think it's necessary to update x/build to require a newer version of cloud, because v0.31.0 did not yet have a go.mod file added yet, so it's not a bad version (because it doesn't require any bad versions of other modules).

[gopherbot]

Change https://golang.org/cl/169517 mentions this issue: [dev.boringcrypto] misc/boring: add go1.12.1b4 and update build scripts

[thepudds]

@dmitshur sorry, not sure what I did, but I did not mean to close this.

[dmitshur]

By now, none of the required module versions in x/build's go.mod requirement list are problematic. However, there were three remaining modules whose latest released version needed to be fixed (and until it was fixed, running go get -u on x/build would upgrade to them, triggering the problem).

The latest versions (released today) of the modules cloud.google.com/go, google.golang.org/api, and go.opencensus.io (v0.37.3+, v0.3.1+, and v0.20.1+, respectively) have expunged the problematic github.com/golang/lint module path from their build list.

As a result, this go get -u problem has been resolved in x/build as well.

Doing the following results in successful output:

$ cd $(mktemp -d)
$ git clone https://go.googlesource.com/build .
$ export GO111MODULE=on
$ go get -u -m
...
$ echo $?
0

Thank you very much @jadekler and everyone else involved for your work on resolving this problem!