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

[skitt]

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/metadata@v0.2.1
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/go@v0.97.0/compute/metadata)
	cloud.google.com/go/compute/metadata v0.2.1 (/home/skitt/go/pkg/mod/cloud.google.com/go/compute/metadata@v0.2.1)

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/go@v0.104.0
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/metadata@v0.2.1
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.)

[codyoss]

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]

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

[skitt]

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.

[liggitt]

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]

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)