Google-cloud-python: Determine how to support emulators consistently across all clients.

[theacodes]

There are emulators available for several APIs (such as Datastore and Pub/Sub). We need to figure out the right client patterns to support these across the board. This issue is to discuss our options.

Also relates to googleapis/google-cloud-python#3920

[chemelnucfin]

See googleapis/google-cloud-python#4897 also for storage related questions.

[rvandegrift]

Shouldn't the libraries just use the env vars that trigger the SDK to connect to the emulators?

For instance, to use the Datastore emulator, you set DATASTORE_EMULATOR_HOST=<host>:port. That's enough indication that google.cloud.datastore.Client should skip credentials and connect directly to the emulator.

What is the reason for thinking that some other interface is required? IMO, if I have to set anything else, it's a worse developer experience.

[theacodes]

That's one option. The description of the bug is the figure out the right client patterns, and that includes considering implicitly using emulators when env vars are set.

[rvandegrift]

Would an implementation of this approach be merged? Seems like there hasn't been another idea in the past year

[brandonjbjelland]

Requisite: Thank you much for maintaining these libraries. They're super dope and I want to see them continue growing in awesome ways!

Chiming in to support @rvandegrift 's approach and hopefully nudge this forward. This approach _mostly_ aligns with the way the Node.js library supports working with the emulator. Same concept but a different environment variable pitched here.

If another option is needed to debate, I'll pitch passing a configuration dict/object when instantiating a client. This would would feel plenty idiomatic (boto3.client or Session are reasonable examples) though I gather aren't typically necessary when running against (for example) a production Firestore instance in a given project. I think that's the right consideration - is a configuration block valuable for any of these client libraries when establishing a session (e.g. would it enable some intrepid user to authenticate distinct client sessions to multiple projects/instances of a given product within the same python module space)?

In terms of local development and testing, some solution here seems critical. What's needed to keep this moving?

[deanberris]

Is there an update on this? I'm in the process of attempting to migrate an AppEngine service running in the python27 environment towards using the google-cloud-* client libraries for use in the python37, and testing locally with emulation is critical for integration testing to ensure we're not breaking anything. Is this a regression, maybe something we can work around?