Use Python GAPIC package name to determine Python gRPC package name about artman HOT 2 CLOSED

@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?

from artman.

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.

from artman.