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

go.mod: update dependencies #342

Open
dmitshur opened this Issue Mar 15, 2019 · 9 comments

Comments

Projects
None yet
4 participants
@dmitshur
Copy link

dmitshur commented Mar 15, 2019

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

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

This comment has been minimized.

Copy link
Author

dmitshur commented Mar 15, 2019

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

This comment has been minimized.

Copy link
Author

dmitshur commented Mar 15, 2019

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

This comment has been minimized.

Copy link
Member

broady commented Mar 15, 2019

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

This comment has been minimized.

Copy link
Author

dmitshur commented Mar 15, 2019

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

This comment has been minimized.

Copy link
Member

broady commented Mar 15, 2019

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

This comment has been minimized.

Copy link
Author

dmitshur commented Mar 15, 2019

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

This comment has been minimized.

Copy link
Member

broady commented Mar 15, 2019

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

This comment has been minimized.

Copy link
Author

dmitshur commented Mar 15, 2019

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.

@jadekler

This comment has been minimized.

Copy link
Collaborator

jadekler commented Mar 18, 2019

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.