Use Python GAPIC package name to determine Python gRPC package name

[geigerj]

What

The Python GAPIC package name is currently configured in the GAPIC config. The Python gRPC package name is determined by combining the prefix google.cloud.grpc with the proto package name. For consistency, it would be good to use the same package name structure for both GAPIC and gRPC; that is, any GAPIC package {prefix}.gapic.{suffix} will depend on the gRPC package {prefix}.grpc.{suffix}.

Why

This avoids the verbosity of some proto package names while ensuring a consistent naming strategy across Python packages. See @bjwatson's comment in googleapis/api-client-staging#154

Concerns

The simplest implementation requires artman to read the GAPIC config to obtain the GAPIC package name and pass it to the gRPC package renaming task. I'm wary about introducing a dependency on the GAPIC config for a gRPC pipeline, since none currently exists, and such a dependency is counterintuitive (GAPIC should depend on gRPC, not the other way around).

An alternative is to move package name configuration to the artman config. This has the drawback that the package name must still be propagated to the GAPIC config (so it's duplicated across configs) and introduces the possibility of inconsistency if the GAPIC config is manually edited, but doesn't introduce any new dependencies to the gRPC pipeline.

cc: @bjwatson, @lukesneeringer

[geigerj]

@bjwatson After discussing with @lukesneeringer, I'm opposed to this for a few reasons, mostly related to proto dependencies:

• It requires artman AND toolkit to know not only about the GAPIC config for the API it is generating, but about all GAPIC configs in existence (since protos can import arbitrary other protos)
• A change the configured GAPIC package name in one API potentially entails breaking changes across any API that depends on its protos
• We don't have any good way to handle protos for APIs where there is no GAPIC wrapper, since there is no GAPIC config. Furthermore, introducing a GAPIC config down the road for those protos is a breaking change to any API that relies on them
• It's much more complex to implement this than the currently logic, since both artman and toolkit need to have a mechanism to assign to each proto a single GAPIC config. No such mechanism exists. What happens if two different GAPIC configs list the same proto under their sources?

[geigerj]

Per offline discussion with @lukesneeringer and @bjwatson, the current state of things will be maintained. In summary:

• The package name that appears on PyPI (e.g., proto-google-cloud-errorreporting-v1beta1 and gapic-google-cloud-errorreporting-v1beta1) will be consistent and derived only from the artman config.
• The package path within these PyPI packages (e.g., google.cloud.proto.devtools.clouderrorreporting, google.cloud.gapic.errorreporting) may be inconsistent because the Python-language proto package is derived from the proto-language proto package, and the GAPIC package is derived from the GAPIC config.