Add credentials parameter to read_gbq

[jrbourbeau]

This PR adds a new credentials= kwarg to read_gbq and pipes it down to the appropriate Google client library calls. For testing, I've copied our existing test_to_gbq_with_credentials test (which testing the same thing, but for to_gbq) and added a read_gbq where we pass credentials through.

This seems like the right thing to do, but I'm not very familiar with how Google handles auth. cc @ntabris who has more experience in that department

Closes #77

[ntabris]

Hm, I'd expect this to work, but personally I'd prefer the API to take credentials object, rather than taking the dict. This would give more flexibility, and be more consistent with Google APIs.

[jrbourbeau]

Thanks for taking a look at this @ntabris

personally I'd prefer the API to take credentials object, rather than taking the dict. This would give more flexibility, and be more consistent with Google APIs.

My guess is that folks coming from Dask will be used to passing as dict but, as you said, folks coming from Google APIs will be used to working with credentials objects. I think supporting both is inputs is reasonable. If we're happy with the current state of this PR, I'd like to stick with the dict for now (it matches what we already have for to_gbq) and extend to accepting Google credentials objects as needed in a follow up

[dchudz]

it matches what we already have for to_gbq

Consistency with what we already have in this package seems important, yeah! More important than these other considerations.

[ntabris]

If we're happy with the current state of this PR, I'd like to stick with the dict for now (it matches what we already have for to_gbq) and extend to accepting Google credentials objects as needed in a follow up

Sure.

[j-bennet]

Hm, I'd expect this to work, but personally I'd prefer the API to take credentials object, rather than taking the dict. This would give more flexibility, and be more consistent with Google APIs.

Credenticals object can't be pickled, no such problem with a dict.

[nick-amplify]

@jrbourbeau thanks for adding a fix so fast!!

[jrbourbeau]

I'm going to merge this in as the hanging Python 3.8 build on macOS is unrelated to the changes in this PR (xref #80)