NotificationsYou must be signed in to change notification settings
Fork321
Star786

fix: avoid overly strict dependency on pyarrow 3.x#564

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Jump to bottom

Merged

plamut merged 1 commit intogoogleapis:masterfromtswast:issue563-pyarrow-bignumeric

Mar 22, 2021

Merged

fix: avoid overly strict dependency on pyarrow 3.x#564

plamut merged 1 commit intogoogleapis:masterfromtswast:issue563-pyarrow-bignumeric

Mar 22, 2021

Conversation

Copy link

Contributor

tswast commentedMar 19, 2021

Excludes bignumeric_type from all extra

Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:

Make sure to open an issue as abug/issue before writing your code! That way we can discuss the change, evaluate designs, and agree on the general idea
Ensure the tests and linter pass
Code coverage does not decrease (if any source code was changed)
Appropriate docs were updated (if necessary)

Fixes#563 🦕

fix: avoid overly strict dependency on pyarrow 3.x

d8e5523

Excludes bignumeric_type from all extra

tswast requested review froma team andshollyman and removed request fora team

March 19, 2021 18:40

product-auto-labelbot added the api: bigqueryIssues related to the googleapis/python-bigquery API. label

Mar 19, 2021

google-clabot added the cla: yesThis human has signed the Contributor License Agreement. label

Mar 19, 2021

tswast requested a review fromplamut

March 19, 2021 20:04

Copy link

ContributorAuthor

tswast commentedMar 19, 2021

I suspect that the reason it wasn't failing on Kokoro but it was for me is that our Kokoro setup has an older version of pip that didn't have as strict of dependency resolver.

plamut approved these changes

Mar 20, 2021

View reviewed changes

Copy link

Contributor

plamut left a comment•
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I suppose the assumption is that users who want BIGNUMERIC support will not use "all", but by explicitly specifying the "bignumeric_type" extra?

The change can be breaking for users that decided to use the fairly recently added BIGNUMERIC support through the "all" extra, but that's probably less bad than everyone else on Python3.6 Mac already using the "all" extra, but are now suddenly facing a regression due to a feature they did not voluntarily request.