Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Project ID Detection #245

Closed
wants to merge 1 commit into from
Closed

RFC: Project ID Detection #245

wants to merge 1 commit into from

Conversation

bshaffer
Copy link
Contributor

Adds Project ID Detection in this order:

  • Project ID from Application Default Credentials
  • Project ID from GCLOUD_CONFIG environment variable
  • Project ID from App Engine AppIdentity service
  • Project ID from Compute Engine metadata server
  • Project ID from gcloud default config file

As "Project ID" is only used for API calls to Google Cloud Platform, it makes more sense to put this in google/cloud as opposed to google/auth

 - Project ID from Application Default Credentials
 - Project ID from GCLOUD_CONFIG environment variable
 - Project ID from App Engine AppIdentity service
 - Project ID from Compute Engine metadata server
 - Project ID from gcloud default config file
@googlebot googlebot added the cla: yes This human has signed the Contributor License Agreement. label Nov 16, 2016
@stephenplusplus
Copy link

I'm not sure if this makes a difference, but for Node, this logic went into the auth library (PR). Exposing this detection in a lower level for more libraries to take advantage of would probably be well received.

The other languages were going to put this behavior in the auth layer as well, though I haven't followed their conversations to confirm.

@dwsupplee
Copy link
Contributor

I agree with @stephenplusplus that I could see there being value in detecting the project ID from the auth layer.

Adding on to your point, it does look like ruby plans to add the same support to the auth library as well: googleapis/google-auth-library-ruby#90.

@bshaffer do you think given that we should follow suit?

@bshaffer
Copy link
Contributor Author

We are having this conversation and trying to decide where best to place this. Since project ID is only used in cloud-based APIs, I am of the opinion it should be implemented here.

@jdpedrie
Copy link
Contributor

I don't know if I agree with that @bshaffer. There may not be many first-party libraries that need to determine project IDs, but there are some (the work done by @tomwalder comes to mind) that do interact with the cloud APIs and thus need project IDs. Surely more will come as time goes on, to fill in gaps which google-cloud-php doesn't cover. Easing project ID detection would surely make things simpler for more than just us. 😄

@tomwalder
Copy link

Hey. It would certainly cause some problems for the PHP-GDS library if project ID detection got moved into this library.

What about a distinct library for Project ID detection, which can then be composed in?

e.g. google/google-cloud-project-detect-php

Or something less catchy? :)

@bshaffer
Copy link
Contributor Author

@tomwalder I would prefer to keep things simple if possible. The consensus is in resounding favor of moving this to google/auth, and @jdpedrie brings up a good point.

@bshaffer
Copy link
Contributor Author

bshaffer commented Dec 9, 2016

closing because this will never ever be merged ever

@bshaffer bshaffer closed this Dec 9, 2016
@dwsupplee dwsupplee deleted the add-project-detection branch December 20, 2016 16:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla: yes This human has signed the Contributor License Agreement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants