Should `Blob` and `Bucket` constructors fall back to `_implicit_environ` defaults?

[tseaver]

Bucket.__init__() currently has connection=None as a defaulted argument, and does nothing to "normalize" that value (i.e., by using the one set in _implicit_environ. ISTM that it would be useful to have the following work, assuming the envvars are set:

from gcloud.storage import set_defaults
from gcloud.storage.bucket import Bucket

set_defaults()

bucket = Bucket()

for blob in bucket:
 blob.download_to_filename(os.path.join(tmpdir, blob.name))

Likewise, Blob.__init__() could use the default bucket:

from gcloud.storage import set_defaults
from gcloud.storage.bucket import Blob

set_defaults()

blob = Blob('foobar.pdf')
blob.download_to_filename(os.path.join(tmpdir, blob.name))

[dhermes]

I agree. I intend to tackle this. Was concurrently worried about the actual methods on these classes, which I wanted to straighten out before adding convenience.

[tseaver]

That will likely impact the later items I laid out for #15. I will probably hold off on those until this part lands.

[jgeewax]

Should users have to call set_defaults() ? If they didn't explicitly provide a connection, should we consider implicitly calling set_defaults() for them?

[dhermes]

That is behavior I originally implemented but we later decided not to. The idea behind the decisions was that

• Executing code on their behalf could lead to confusion
• A single line for explicit behavior is not much to ask for

[jgeewax]

Just to double check, couldn't we make this code only execute when it becomes needed?

For example:

from gcloud.storage.bucket import Blob

blob = Blob('foobar.pdf')
blob.download_to_filename(...) # <-- Here we try to hit the wire,
 # see there's no authenticated connection,
 # and call set_defaults()

Whereas if we manually set up a connection (or specified where the credentials were, etc), set_defaults() would never need to be called...

If that were the case... I'd be really happy...

[tseaver]

@jgeewax in particular, executing majyk configuration code at import time makes it impossible / hard for users who need to manage it "properly". Asking the user to make a one-line gesture to get the DWIM doesn't seem onerous to me.

[dhermes]

@tseaver What @jgeewax just demonstrated there could be done not at import time, but at usage time:

In _implicit_environ.py:

DEFAULT_ENVIRON = Environment()

then two things can happen.

1. The user expects auth to "just work":

def download_to_filename(self, filename, connection=None):
 connection = connection or DEFAULT_ENVIRON.connection
 ...

and then the Environment.connection object has a __get__ method (i.e. is a descriptor) which lazily loads based on whatever the no-args storage.set_defaults() would do.
2. The user needs to manage it properly:

storage.set_defaults(foo='bar', connection=cnxn, ...)
# Or maybe
cust_env = Environment(foo='bar', connection=cnxn, ...)
storage.set_defaults(cust_env)

[jgeewax]

Also - just to clarify, what is the process to specify the keyfile path? That is, I know my keys are at "/creds.json" or "/key.p12" (pick whichever you want) and don't want to use the environment variable stuff...

I'm having trouble finding an example snippet of how this works...

[dhermes]

@jgeewax It does not exist ATM.

client.GoogleCredentials.get_application_default() takes no arguments, so we'd need to add methods other than get_credentials() (JSON svc. acct. key only) and get_for_service_account_p12(...).

For a JSON key we could skip right to

from oauth2client.client import _get_application_default_credential_from_file
_get_application_default_credential_from_file(filename)

ISTM that a PKCS12 key is discouraged (based on what the usable auth approach is), hence we have a separate / legacy method.

[jgeewax]

Got it - created #638 ... that seems important...