gspread depends on google-auth>2.4.0 but only specifies google-auth>=1.12.0

[seanabraham]

Describe the bug I have gspread installed against version 1.35.0 of google-auth which is within the constraints currently specified by pyproject.toml (google-auth>=1.12.0) and get the following error upon import gspread:

ModuleNotFoundError: No module named 'google.auth.api_key'.

Looks like this module only came into existence in google-auth v2.4.0 so that's the constraint that should be actually specified

To Reproduce Steps to reproduce the behavior:

1. Install gspread alongside any version of google-auth less than 2.4.0
2. Import gspread
3. Observe ModuleNotFoundError: No module named 'google.auth.api_key'.

[lavigne958]

Hi, I'm sorry about this issue ! I did not notice that the api_key does not exists in newer version :disappointed:

I will have a look and see how we can solve this.

[lavigne958]

I check the dependencies, this going to be annoying to solve :disappointed:

• We introduced a breaking-change when adding the API Key authentication

In order to solve it properly, I suggest, @alifeee let me know if you think of something better

1. add a new warning on the auth method api_key() that it's going to move to version 7.0.0
2. release version 6.1.1 to let everyone get the warning
3. wait for some time (I believe a couple of weeks at least ? ) for everyone to adapt
4. remove the auth method api_key() :cry:
5. release version 6.2.0 -> auth method api_key() does not exists anymore
6. add it back
7. bump dependency to at least version 2.4.0 for google_auth
8. release version v7.0.0

this way anyone with a dependency on google_auth < 2.4.0 can use gspread-6.2.2 Anyone else not blocked by this version can benefit of the new auth method.

[seanabraham]

Sounds like a good plan to me. My personal solution was to upgrade dependencies but it was a complex web requiring a lot of updates and it would have been nice to have an option to still use gspread

[alifeee]

what do you think of the following change?

https://github.com/burnash/gspread/compare/master..fix/api_key-auth-version

Firstly, test-requirements.txt uses the minimum versions specified by pyproject.toml.

Secondly, the import is attempted but silently fails. It is only noticeable if you are using api_key for auth, in which case you will get an exception. Here is what it would look like to use with the following code

from gspread.auth import api_key

api_key("uijwaiofjwa")

I think this keeps backwards compatibility (people can still use gspread on low versions of google-auth), while also allowing api_key to be used if desired (i.e., not removing the feature), with hopefully a nice error message.

Then, we can think in future of increasing the minimum version in pyproject.toml, and removing this fix.

[lavigne958]

@alifeee thats looks great !

correct me if I'm wrong, the plan is:

• merge this fix on imports
• make a new release (6.1.1 - it's a bugfix only)
• later on....
• remove the fix
• bump dependency to a more recent version where api_key exists
• release 7.0.0 (it's a breaking change as we bump the dependency to a new major version too)

if this is correct I think we should merge whatever fix we have to merge now + new features that have been waiting, then start working on version 7.0.0, what do you think ?

[alifeee]

sounds good. we should make a PR from https://github.com/burnash/gspread/compare/master..fix/api_key-auth-version

not sure if it's that testable, will need a bit of manual testing, as version numbers are being screwed around with

I am in no rush to release 7.0.0. This bugfix seems reasonable to me as api_key is not a widely used method (I think) so it will not affect many people.

[lavigne958]

sounds good. we should make a PR from https://github.com/burnash/gspread/compare/master..fix/api_key-auth-version

not sure if it's that testable, will need a bit of manual testing, as version numbers are being screwed around with

I am in no rush to release 7.0.0. This bugfix seems reasonable to me as api_key is not a widely used method (I think) so it will not affect many people.

agreed, we could simply fix it and keep going with new workaround.