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

compute/metadata: dependency on compute doesn’t avoid ambiguous imports in all cases #7209

Closed
skitt opened this issue Jan 4, 2023 · 5 comments
Labels
api: compute Issues related to the Compute Engine API. type: question Request for information or clarification. Not an issue.

Comments

@skitt
Copy link

skitt commented Jan 4, 2023

https://github.com/googleapis/google-cloud-go/blob/main/compute/metadata/tidyfix.go#L23 is supposed to allow safe module upgrades, but it isn’t sufficient in all cases; specifically, when an existing dependency on cloud.google.com/go is present with an old enough version.

Starting from k/k master (commit kubernetes/kubernetes@0b2e541 right now):

$ go get cloud.google.com/go/compute/[email protected]
cloud.google.com/go/compute/metadata: ambiguous import: found package cloud.google.com/go/compute/metadata in multiple modules:
	cloud.google.com/go v0.97.0 (/home/skitt/go/pkg/mod/cloud.google.com/[email protected]/compute/metadata)
	cloud.google.com/go/compute/metadata v0.2.1 (/home/skitt/go/pkg/mod/cloud.google.com/go/compute/[email protected])

k/k has an indirect dependency on cloud.google.com/go v0.97.0. Bumping that to v0.104.0 allows the upgrade to complete:

$ go get cloud.google.com/[email protected]
go: upgraded cloud.google.com/go v0.97.0 => v0.104.0
go: upgraded github.com/google/uuid v1.1.2 => v1.3.0
go: upgraded github.com/googleapis/gax-go/v2 v2.1.1 => v2.4.0
go: upgraded golang.org/x/oauth2 v0.0.0-20220223155221-ee480838109b => v0.0.0-20220622183110-fd043fe589d2
go: upgraded google.golang.org/api v0.60.0 => v0.93.0
go: upgraded google.golang.org/genproto v0.0.0-20220502173005-c8bf987b8c21 => v0.0.0-20220822174746-9e6da59bd2fc

$ go get cloud.google.com/go/compute/[email protected]
go: upgraded cloud.google.com/go/compute v1.7.0 => v1.12.1
go: added cloud.google.com/go/compute/metadata v0.2.1
go: upgraded github.com/googleapis/gax-go/v2 v2.4.0 => v2.6.0
go: upgraded golang.org/x/oauth2 v0.0.0-20220622183110-fd043fe589d2 => v0.0.0-20221014153046-6fdb5e3db783
go: upgraded google.golang.org/api v0.93.0 => v0.100.0
go: upgraded google.golang.org/genproto v0.0.0-20220822174746-9e6da59bd2fc => v0.0.0-20221024183307-1bc688fe9f3e

(Yes, I know that’s not how k/k dependency bumps are supposed to be handled, this is just for illustrative purposes.)

@skitt skitt added the triage me I really want to be triaged. label Jan 4, 2023
@product-auto-label product-auto-label bot added the api: compute Issues related to the Compute Engine API. label Jan 4, 2023
@codyoss codyoss added type: question Request for information or clarification. Not an issue. and removed triage me I really want to be triaged. labels Jan 4, 2023
@codyoss
Copy link
Member

codyoss commented Jan 4, 2023

I believe this is to be expected and nothing can be done to avoid that case. The only way to avoid the ambiguous import is to upgrade cloud.google.com/go to the version referenced in the mod of compute/metadata. If you upgrade to the latest compute/metadata this weak ref was re-added for the time being to help facilitate an easier migration.

@codyoss
Copy link
Member

codyoss commented Jan 4, 2023

This is all related in a way to kubernetes/kubernetes#113366

@skitt
Copy link
Author

skitt commented Jan 4, 2023

Right, I was wondering if this could be handled in cloud.google.com/go/compute somehow but that already has an appropriate dependency on cloud.google.com/go. AFAICT reliably fixing this would require adding a dependency from /go/compute/metadata to /go, defeating the purpose of the metadata split.

@skitt skitt closed this as completed Jan 4, 2023
@liggitt
Copy link
Contributor

liggitt commented Jan 4, 2023

If you upgrade to the latest compute/metadata this weak ref was re-added for the time being to help facilitate an easier migration.

that sort of defeats the purpose of the isolated module, right?

@liggitt
Copy link
Contributor

liggitt commented Jan 4, 2023

The only way to avoid the ambiguous import is to upgrade cloud.google.com/go to the version referenced in the mod of compute/metadata.

I agree with this, but did not expect the metadata module to add a backref that forces all consumers of that module to also depend on cloud.google.com/go (and transitively, on all other submodules)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: compute Issues related to the Compute Engine API. type: question Request for information or clarification. Not an issue.
Projects
None yet
Development

No branches or pull requests

3 participants