Ideally, we will do this in a generic way. There may be other plugins that people want to use. We should support those.
See https://github.com/adap/flower/blob/main/src/flwr_tool/protoc.py for an example of how to call Protoc.
+1. Would love to see this!
Hey @pmohan6 and @danieljanes. Question: would you envision every protobuf_library generating gRPC in a huge monorepo, or only some of your Protobuf code using gRPC?
I'm thinking we will want a new field on protobuf_library:
protobuf_library(grpc=True)
Rather than a global toggle that always uses gRCP. I don't imagine that scaling well.
--
Similar question for MyPy protobuf. We could either have a per-target field, or have a global toggle. For MyPy, we might want a global toggle? I'm not sure when you would ever not want type stubs generated.
--
A third design is to have the per-target fields, and also have a global toggle which acts as the default. You can change default behavior by using the global toggle, and still override it at the target level. The downside of this approach is that it's more complex, such as being harder to document.
Hi @Eric-Arellano , thanks for asking! We don't use gRPC in every ProtoBuf file, just in some of them, so a per-target option is good. For mypy we don't have any use cases where we'd want to disable type stub generation, but that's just our perspective. Perhaps one might want to disable it to reduce the size of generated code/artifacts, but we like to include type defs in our open-source wheels to improve usability.
@Eric-Arellano - Thanks for checking in!
grpc - per-target field makes sense
mypy protobuf - global toggle works better since we don't have a use case either where we would want to disable type stub generation.