This is going to be very confusing for users: we havethree similarly-named arguments, one of which is deprecated, all of which exist to allow users to override bits of the default configuration for the client. Could weadd theapi_endpoint attribute togoogle.api_core.client_info.ClientInfo?

This client options class is designed to be the central place for client-level user configuration, not just for endpoints. We are planning to add credentials, pre-defined headers and other stuff.

I agree that right now it seems like we have 'client_config', 'client_info' and 'client_options' which all look the same. Is it possible that we merge these similar classes into one?

We can look into rolling the others into client_options, since that is the "new" name that's going to be used across clients.

@busunkim96 I don't think you've addressed the confusion factor here: why do we want people to configure the client using bothclient_info andclient_options (leaving aside my never-answered question of whyclient_config is deprecated)?

Please correct me if any of this isn't correct, but I think:
client_config -> this is about gRPC timeout/retry configuration
client_info -> this should probably nameduser_agent_info or something more accurate. This is the data attached to requests to identify the particular client better.
client_options -> this new property bag, currently for endpoints. Eventually also additional things.

It is possibleuser_agent_info should also be underclient_options

Your description of the three arguments roles is correct. I'm arguing that three is two too many. Users should only need to thing about one thing to pass in to customize the behavior of the client.

@lukesneeringer Can you please comment on whyclient_config is deprecated? How else would users be expected to tweak e.g. gRPC timeouts for client-invoked methods?

Here is alink to the extensible options in Python doc that should be accessible to all ofyoshi-team@google.com. It has more context about Client Options and what we're looking to add to it in the future.

The goal ofclient_options is to have a more straight-forward way to configure clients. We want to provide a consistent interface to set options across the generated, handwritten, and Apiary clients. The experience will also be more predictable across languages.

User agent is on the list of things we would like to be configurable withclient_options. I think we want to move what is inclient_info (user agent) intoclient_options. In the near term users will be able to use both, with the user_agent inclient_options taking precedence. We will deprecateclient_info eventually.

Luke's response as to why client_config was deprecated:

The original rationale for deprecating that was that the client options were grpc specific and may not work well with other transports.

The idea was to use the transport itself as the replacement. Based on a request from Chris recently, however, we might need to rethink that, possibly by allowing folks to specify the arguments to the transport that are passed through (without having to instantiate the transport themselves).

This client options class is designed to be the central place for client-level user configuration, not just for endpoints. We are planning to add credentials, pre-defined headers and other stuff.

I agree that right now it seems like we have 'client_config', 'client_info' and 'client_options' which all look the same. Is it possible that we merge these similar classes into one?

This would allow users to do something like:

client = pubsub_v1.PublisherClient(client_options={"api_endpoint": "...", "user_project": "..."})