go.mod: update dependencies

[dmitshur]

The latest tagged release version of this module is v0.2.0. Its go.mod file requires:

google-api-go-client/go.mod

Line 7 in e742f5a

go.opencensus.io v0.19.1

go.opencensus.io@v0.19.1 requires google.golang.org/genproto@v0.0.0-20181219182458-5a97ab628bfb module, which in turn requires a bad grpc v1.16.0 module, resulting in an import of "github.com/golang/lint". See googleapis/google-cloud-go#1359 and golang/lint#436 for background.

The go.opencensus.io module has recently updated its dependencies and dropped the required google.golang.org/genproto v0.0.0-20181219182458-5a97ab628bfb module, which was causing trouble. It hasn't made a new tag yet, but according to census-instrumentation/opencensus-go#1052 (comment), they plan to soon. /cc @bogdandrutu

However, I'm seeing a circular problem. The go.mod of latest master commit of opencensus requires v0.2.0 of this module, which in turn requires an older version of opencensus, which in turn requires the genproto module version which it in turn requires the bad grpc v1.16.0 module.

It seems both of these modules need to coordinate making a tagged release in order to drop the bad previous version of each other.

/cc @broady

[dmitshur]

A possible way to proceed, requiring coordination on both sides.

If @bogdandrutu plans to make a new tag of go.opencensus.io at v0.19.2, and the project owners here are willing to make a new release of google.golang.org/api, for example v0.2.1, then go.mod of go.opencensus.io can be updated to require google.golang.org/api@v0.2.1 before issuing its new v0.19.2 release, and the go.mod of google.golang.org/api can be updated to require go.opencensus.io@v0.19.2 and tag that as v0.2.1.

In both cases, it requires requiring a future tag of the dependency before it's been published. I'm not sure if there's another way out of this situation, but let me know if you see one. Thoughts on this?

/cc @bcmills @heschik

[dmitshur]

I'm not sure if there's another way out of this situation, but let me know if you see one.

I do see another way. It would require one of the projects to temporarily omit the other in its go.mod file and issue a new release. Then the other project can be updated to require the new version. Afterwards, the missing require can be re-added (at the newer, good, version).

[broady]

I think the co-ordinated tag sounds doable.

It would require one of the projects to temporarily omit the other in its go.mod file and issue a new release.

Does that produce a bad version? What is Go modules behavior here?

[dmitshur]

Does that produce a bad version? What is Go modules behavior here?

It does not. When a module is needed but not specified in a given go.mod file, the go command figures one out on demand, using the same rules as when you do go mod tidy, go get, etc.

The downside of leaving it out is that the build will not be 100% reproducible, since the exact version of the required module that's left out is unspecified, and what go picks may change over time. But doing it temporarily is okay, since a future version can be made fully specified and 100% reproducible.

[broady]

The downside of leaving it out is that the build will not be 100% reproducible.

I like @bcmills idea slightly more, then. This way our CI still passes. It seems like we might need to do this across a few more packages to really break the chain. Do we know for sure all the packages we need to touch, @dmitshur?

[dmitshur]

I like @bcmills idea slightly more, then.

Which one are you referring to?

Do we know for sure all the packages we need to touch, @dmitshur?

I tried to look through everything that was relevant and only found these two, but there is a chance I overlooked something.

[broady]

Which one are you referring to?

Brain fart. I don't know why I thought he wrote the comment above:

It would require one of the projects to temporarily omit the other in its go.mod file and issue a new release.

This idea seems slightly preferable.

[dmitshur]

Do we know for sure all the packages we need to touch, @dmitshur?

I tried the following locally. Made an new module with a go.mod like this:

module m

require (
	go.opencensus.io v0.19.2
	google.golang.org/api v0.2.1
)

replace (
	go.opencensus.io v0.19.2 => /tmp/oc-next
	google.golang.org/api v0.2.1 => /tmp/api-next
)

/tmp/oc-next was a local checkout of latest master of https://github.com/census-instrumentation/opencensus-go with the following diff:

diff --git a/go.mod b/go.mod
index b59bf6c..4591f99 100644
--- a/go.mod
+++ b/go.mod
@@ -8,6 +8,6 @@ require (
        github.com/openzipkin/zipkin-go v0.1.6
        github.com/prometheus/client_golang v0.9.3-0.20190127221311-3c4408c8b829
        golang.org/x/net v0.0.0-20190311183353-d8887717615a
-       google.golang.org/api v0.2.0
+       google.golang.org/api v0.2.1
        google.golang.org/grpc v1.19.0
 )

/tmp/api-next was a local checkout of latest master of https://github.com/googleapis/google-api-go-client with the following diff:

diff --git a/go.mod b/go.mod
index f162cdfe9..2c775740d 100644
--- a/go.mod
+++ b/go.mod
@@ -4,7 +4,7 @@ go 1.12
 
 require (
        github.com/google/go-cmp v0.2.0
-       go.opencensus.io v0.19.1
+       go.opencensus.io v0.19.2
        golang.org/x/lint v0.0.0-20190301231843-5614ed5bae6f
        golang.org/x/oauth2 v0.0.0-20190226205417-e64efc72b421
        golang.org/x/sync v0.0.0-20190227155943-e225da77a7e6

Then I did go get -u -m in the main module. And I still ran into the github.com/golang/lint error. So I think that means there's more that needs to be done.

[jeanbza]

Thanks for the continued investigation @dmitshur.

Then I did go get -u -m in the main module. And I still ran into the github.com/golang/lint error. So I think that means there's more that needs to be done.

Does go mod graph indicate that the bad version of gRPC is still imported? And if so, which library is depending on it?

[jeanbza]

I've removed the go 1.12 statement from our go.mod in the latest v0.3.0 release. AFAICT from my own testing, this appears to have fixed the issue. Please report back if you note otherwise.

[thapakazi]

Thanks for the patch, not sure what you did, but you just fixed my troubles with go mod and sheets.

PASS
ok      myapp_using_googlesheet.git    22.069s

[jeanbza]

Oh, good to hear! :D

[jeanbza]

Note - if anyone is still having go get -u problems, please upgrade to (for whichever you depend on):

• cloud.google.com/go v0.37.4
• google.golang.org/api v0.3.2
• go.opencensus.io v0.20.1

[jamesabbottsmith]

@jadekler there isn't a v0.3.4 tag for google.golang.org/api (it only goes up to v0.3.2) (See GitHub tags).

go get -u
go: finding google.golang.org/api v0.3.4
go: google.golang.org/api@v0.3.4: unknown revision v0.3.4
go: error loading module requirements

[dmitshur]

@jamesabbottsmith I believe it was a typo. It should say v0.3.2 for google.golang.org/api. The other two versions look correct. Of course, newer tags are okay to use too.

[jeanbza]

Whoops, sorry! Getting my tags mixed up. Yes, 0.3.2 is correct. I'll go update my comments elsewhere.