Google-cloud-python: New releases to pick up latest version of google-cloud-core

[liyanhui1228]

Can we release new versions for all the libraries that depending on google-cloud-core? #6835 and #6858 are checked in for updating the dependency version, we just need to release the changes. Depending on an old version would potentially causing version conflicts for users.

e.g trace and bigquery are not compatible with each other: google-cloud-trace 0.20.1 has requirement google-cloud-core<0.30dev,>=0.29.0, but you have google-cloud-core 0.28.1.

[tseaver]

$ git grep -l "google-cloud-core" | grep setup.py
bigquery/setup.py
bigtable/setup.py
core/setup.py
datastore/setup.py
dns/setup.py
firestore/setup.py
logging/setup.py
resource_manager/setup.py
runtimeconfig/setup.py
spanner/setup.py
storage/setup.py
trace/setup.py
translate/setup.py

[tseaver]

Looks like google-cloud-trace is the only one which has had a release since the update to the google-cloud-core dependency in 9908ed55bd9940852ca410a24a568c2c5c2d4f71.

[crwilcox]

Trace needed a release last week for a bug. That does indeed mean we need to release new versions of the libs. I will start in on that.

[crwilcox]

• [x] bigquery (#6890)
• [x] bigtable (#6891)
• [x] core
• [x] datastore (#6889)
• [x] dns (#6892)
• [x] firestore (#6902)
• [x] logging (#6893)
• [x] resource_manager (#6894)
• [x] runtimeconfig (#6895)
• [x] spanner (#6896)
• [x] storage (#6897)
• [x] trace
• [x] translate (#6898)

[zunger-humu]

Problem: It looks like the latest google-cloud-core removes google/cloud/iam.py, but the live version of the storage library (at least) depends on it. So code is actively broken right now. Do we have an ETA on pushing google-cloud-storage? Or failing that, should we consider a rollback?

[tseaver]

@zunger-humu See #6897, which should lead to a release today.

[tseaver]

@zunger-humu https://pypi.org/project/google-cloud-storage/1.13.1/

[tseaver]

Firestore has a couple of outstanding issues blocking a release; we expect to resolve those and make a release this week.

[dhendry]

This firestore dependency conflict has broken our pipenv configuration and there does not seem to be a good fix which is incredibly disruptive to our development process. As a suggestion, would you consider adopting some kind of standard like restricting the upper bound on the dependent versions to something like next + 1? Using the current firestore setup.py as an example, instead of

google-cloud-core >= 0.29.0, < 0.30dev',

use

google-cloud-core >= 0.29.0, < 0.31dev',

Presumably most versions are going to forwards compatible by at least one release.

[crwilcox]

All libraries have had new releases that will resolve the conflicts. This was unfortunately necessary to make way for a new client. Sorry for the disruption.

[liyanhui1228]

Thanks for releasing the new versions! To avoid future version conflicts it would be helpful if we could release all the libraries whenever we update the version of google-cloud-core.

Do we have a plan to migrate all the dependencies of google-cloud-core to google-api-core? The latter one is GA and enforced semantic versioning, which can ensure we won't hit the dependency hell again theoretically.

[crwilcox]

@liyanhui1228 correct. The plan is to deprecate google-cloud-core. This was the last (planned) update to this package to resolve a name collision between google.cloud.iam (core) and google.cloud.iam (new client library)

[liyanhui1228]

Is that possible to allow the previous google-cloud-core version in the google-cloud-bigquery library? This is causing apache-beam[gcp] (previous named google-cloud-dataflow) to have conflicts with all the cloud client libraries because it is using an old version of bigquery client library. We will talk to them to update the bigquery dependency but their next scheduled release will happen a month later.

I know that other client libraries will potentially have the same problem as the bigquery one, but it will be great that at least we are compatible with our gcp owned libraries. Thank you so much for any help!