Get project name from the service account?

[mwilliammyers]

Is there a reason why from_credentials takes a project name as well? I am just trying to eliminate the friction in setting up the credentials with e.g. multiple environment variables/secrets for testing etc.

I see a few options:

1. Get the project name from the service account and allow setting a different project name per request (sometimes that makes sense for GCS when using e.g. another project's bucket)
2. Get the project name from the service account and allow setting a global project_id/name on the client object later
3. Accept an Option and default it to the project_id found in the service account file
4. A hybrid approach where we do 2 or 3 and then also let the user specify a project_id per request if need be (in an ergonomic way, so we aren't passing None around a bunch when we want to just use the project_id in the client for the request...)

I think I am leaning towards option 4...

[Hirevo]

I did this because of the Golang client for GCP also does explicitly ask for a project name:

// The Pub/Sub client asks for it upfront.
pubsub.NewClient(ctx, "project-name")

// The GCS client is a bit weird, it doesn't ask for it at client-creation time.
client, _ := storage.NewClient(ctx)
// But it asks for it when listing buckets
client.ListBuckets(ctx, "project-name")
// But doesn't at all for bucket-specific operations
bucket := client.Bucket("my-bucket")
bucket.Delete(ctx)
// (my guess is that since two buckets can't share a given name, even if from separate projects, it infers the project name through the bucket)
// (but the inconsistency can be disturbing at times)

Because of the inconsistencies in storage, I preferred always asking for it upfront.

But I agree that we could probably offer the option to infer it from the credentials.
One property that could be of interest and that we could lose if we were to infer the project name is that, if a user uses the wrong credentials in its environment, always specifying it in code allows to catch that misuse (because the calls would fail) instead of creating and/or deleting resources on a different project than the one intended.