_try_credentials requires read permissions

[telenieko]

Hi,

I am trying out pandas-gbq as part of a data loading process (we load lots of stuff into DataFrame's for cleanup and processing, and the final result is loaded into BigQuery).

On that use case, the account used needs only write access to BigQuery but _try_credentials issues a SELECT which makes it fail.

Moreover, this is run on GCP so google.auth.default() succeeds but as the SELECT fails, the library tries interactive authentication which fails.

Either _try_credentials should not require read permissions (unless on a read operation) or the method should be optional.

Related to #198

[max-sixty]

Thanks for the issue @telenieko

I think supporting write-only creds is probably further off than some of the more immediate auth changes; though we may get it for free after some of the clean-up.

If you need this sooner, you could try:

• Uploading to a dataset or project with read+write auth, and then a separate script to copy the tables to the dataset you don't want to allow read auth
• As a last resort, you could try monkey patching _try_credentials to avoid running the SELECT 1 query
• You could also try using google.cloud.bigquery, though you lose some of the wrappings that pandas_gbq provides

[telenieko]

Thanks for the quick reply.
I am currently monkey patching _try_credentials :)

[max-sixty]

If this works well for you, I'd be very open to a PR that offered an option to skip that step.

(though @tswast let us know if you think that's a poor middle ground prior to the auth overhaul)

[tswast]

I'm still thinking about how we want to handle try_credentials in the future. The main reason it's used right now is to avoid the problem that GCE credentials might not work even if you can get them because they have the incorrect scopes.

I have a try_credentials argument over in https://github.com/pydata/pydata-google-auth where I'm doing some of the auth refactoring, but could be convinced to drop them. For example, I don't know how we'd safely check for write permissions. It'd probably be fine for the API to fail in this case, and expect the user to manually specify user credentials if they don't like the default credentials.

[tswast]

A short-term solution could be to only run _try_credentials for read_gbq and not to_gbq. I'd welcome a PR that does that.

[max-sixty]

It'd probably be fine for the API to fail in this case, and expect the user to manually specify user credentials if they don't like the default credentials.

I imagine, with fairly low confidence, that users with such defined permissions are a) not that common, b) sophisticated enough to supply the correct creds

Edit: ...and so 👍 to your suggestion