Without this change, I get errors like:

ERROR: [...]/googleapis/google/api/BUILD.bazel:537:1: no such target '//:grpc_python_plugin': target 'grpc_python_plugin' not declared in package '' defined by [...]/googleapis/BUILD.bazel and referenced by '//google/api:_annotations_py_proto_grpc_codegen'

cc @htuch @vam-google @bogdandrutu

@g-easy Can you explain your use case? This was not a rule that we intended to make public. We're not opposed to doing so, but we don't want to unnecessarily tie ourselves to an API that hasn't gone through a thorough review. Once it's out in the wild, we're married to it.

We were actually hoping that this rule would just be an interim solution and we'd move to https://github.com/stackb/rules_proto once their python issues are cleared up. (Speaking of which, they appear to have been closed since I last looked.)

I need to add py_proto_libraries to googleapis for envoy to consume. @vam-google asked me to use grpc's py_proto_library instead of the one from protobuf (which uses srcs="file.proto" instead of deps="proto_library_target").

I'm willing to make the rule public with two caveats:

1. The name should be changed to grpc_py_proto_library to indicate that this is gRPC Python generated code. This will be in line with the C++ rule. Since this was an internal rule before, that fact was implicit.
2. We mark the rule experimental in its docstring.

You can accomplish the first item with

find src examples bazel -name 'BUILD' -o -name '*.bzl' -o -name BUILD.bazel | xargs sed -i 's/py_proto_library/grpc_py_proto_library/g'

The name change will also require an accompanying internal change. I can take care of that part. Once this PR is complete in terms of content, I'll shepherd it through the import process.

Could we please have separate rules for py_proto_library versus py_grpc_library to match the other languages? :)

@vam-google - could you please elaborate why you wanted this rule instead of the one from protobuf?

Related issue: bazelbuild/bazel#3935

@g-easy This rule is in line with C++. Both rules by default generate both protobuf code and gRPC stubs. By setting the proto_only flag to true, you can produce just the protobuf code.

The missing piece is the py_proto_library rule referenced in the issue you linked. C++ has one already. This is provided by the Blaze team internally. I would definitely like to mirror the internal structure as much as possible. And if that means gRPC team needs to take on that work, we can do that. But it will take a little time and coordination with the Bazel team.

@dslomov @brandjon Thoughts?

Let me elaborate on the problem a bit more deeply for context.

What we're seeing is an asymmetry between the rules provided internally and those available in open source. Internally, the ecosystem is as follows:

• proto_library which takes in a .proto file and produces a language-agnostic descriptor file corresponding to that protobuf. This rule is provided by Blaze itself.
• py_proto_library which takes the descriptors produced by proto_library and generates a Python module capable of serializing/deserializing that protobuf. This rule is also provided by Blaze itself.
• google3_py_grpc_library which takes a descriptor file and protobuf python module and produces gRPC stubs. This rule is provided by the gRPC team.

So the py_proto_library rule in this repo is a combination of the functionality of the internal py_proto_library and google3_py_grpc_library rules. This naming was unfortunate, given the clash with the rule available internally.

Edit: The protobuf team also offers a py_proto_library rule, but they also take the stance that it is for internal use only. This seems like a pretty big gap for anyone wanting to use Bazel with Python.

CC @nicolasnoble

CC @kyessenov

@g-easy From the response on bazelbuild/bazel#3935, it doesn't sound like we should hold out hope for native Bazel support in the near term future. I'll work on a split-up of py_proto_library later today if that will get you unblocked.

I think py_proto_library would be valuable for many projects. I have filed issue #19255 for this, and will close my PR since it doesn't look like it has anything in common with the long-term solution for this.

Thanks!