You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Uploading a file with storage and a different key is ... confusing? #787
@jgeewax#591 and #633 are still open, but we wanted to get storage "stable" before doing them. Auth / defaults in storage are still not stable due to #728.
#633 is important -- totally agree, but I still want a way to specify a key path in code. Without this method, we're effectively saying that you should import sys.environ and update a special item on that dictionary rather than providing a method that let's you specify a key.
And what if we want to use multiple keys (say I have two accounts and want to upload two files to two different projects) ?
People don't set environment variables in code, they do it in the environment (so we're not asking people to touch sys.environ)
Using multiple credentials is possible in storage just as we've discussed it's possible in datastore. There is a library-wide concept of Connection (implemented in each sub-package with API specific features) and both explicit and implicit connections can be used whenever an HTTP request is needed. To explicitly create a Connection, a set of credentials from oauth2client can be used. We provide methods in gcloud.credentials to make this easy. These are already "documented" though below the fold. Hence the remaining piece of the puzzle is adding this in an auth document (Add auth doc; Document 3LO via "gcloud login" #633).
You don't need the scope when creating the credentials. We use connection.get_scoped_connection to add credentials within each subpackage. (Though I now realize we could check this in Connection constructors)
It's not necessary to construct a connection and then set it as the default. Though in the "two at once" scenario, you would want them explicitly. Instead of setting the default you'd pass it in
storage.get_bucket('my-bucket', connection=conn)
As for enabling storage.set_credentials_json, it's already possible via setting the environment variable. This is just a more declarative / explicit synonym.
We may consider adding optional keywords to get_connection(), but we tried it before and were stymied by the number of possible accounts that could be used.
Activity
dhermes commentedon Mar 31, 2015
@jgeewax #591 and #633 are still open, but we wanted to get
storage"stable" before doing them. Auth / defaults in storage are still not stable due to #728.I'd like to close this and just focus on #633.
To answer your question, the recommended way to get auth is:
GOOGLE_APPLICATION_CREDENTIALSenv. var. to path of JSON keygcloud auth loginand library picks it upjgeewax commentedon Apr 6, 2015
#633 is important -- totally agree, but I still want a way to specify a key path in code. Without this method, we're effectively saying that you should import
sys.environand update a special item on that dictionary rather than providing a method that let's you specify a key.And what if we want to use multiple keys (say I have two accounts and want to upload two files to two different projects) ?
dhermes commentedon Apr 6, 2015
sys.environ)storagejust as we've discussed it's possible indatastore. There is a library-wide concept ofConnection(implemented in each sub-package with API specific features) and both explicit and implicit connections can be used whenever an HTTP request is needed. To explicitly create aConnection, a set of credentials fromoauth2clientcan be used. We provide methods ingcloud.credentialsto make this easy. These are already "documented" though below the fold. Hence the remaining piece of the puzzle is adding this in an auth document (Add auth doc; Document 3LO via "gcloud login" #633).jgeewax commentedon Apr 6, 2015
Got it, looks like the code I'd have to write is....
Is that right?
If so, it seems a bit verbose (and I don't know exactly what to put down as the
scope). Probably worth shortcutting that to a single line, no?dhermes commentedon Apr 6, 2015
Yes, except for
get_for_service_account->get_for_service_account_jsonconnection.get_scoped_connectionto add credentials within each subpackage. (Though I now realize we could check this inConnectionconstructors)As for enabling
storage.set_credentials_json, it's already possible via setting the environment variable. This is just a more declarative / explicit synonym.We may consider adding optional keywords to
get_connection(), but we tried it before and were stymied by the number of possible accounts that could be used.dhermes commentedon Aug 28, 2015
No longer relevant in
Clientcontextchore: exclude `.nox` from linting; add pre-commit hook (#64)
chore: exclude `.nox` from linting; update python versions in CONTRIB…
chore: exclude `.nox` from linting; document supported python versions (
chore: exclude `.nox` from linting and update pre-commit version (#13)
chore: exclude `.nox/` from linting; update python versions in CONTRI…
18 remaining items
chore(deps): update all dependencies (#787)
chore(deps): update all dependencies (#787)
chore: Re-generated to pick up changes from synthtool. (#189)
chore: release 0.40.11 (#787)
docs(python): document adding Python 3.9 support, dropping 3.5 support (
docs(python): document adding Python 3.9 support, dropping 3.5 support (
chore: exclude `.nox` from linting; add pre-commit; document supporte…
chore: update templates (#60)
chore: docs, tests, and formatting updates via generator (#305)
chore(deps): update dependency google-cloud-logging to v3.7.0 (#787)
chore(deps): update dependency google-cloud-logging to v3.7.0 (#787)
fix: remove expired ack_ids (#787)
fix: issue a warning if buggy pyarrow is detected (#787)
tests: move range read test (#787)
chore: update templates (#289)