raboof
commented
6 years ago We're not allowed to add our own options here, since following https://developers.google.com/protocol-buffers/docs/proto3#options the allowed options are enumerated in descriptor.proto (I guess https://github.com/grpc/grpc/blob/master/third_party/nanopb/generator/proto/google/protobuf/descriptor.proto#L231?).
The CodeGeneratorRequest which is the API used when calling Protoc generators allows a 'parameter' field, which can be used to pass in parameters. We already use this to pass the flat_package option to scalapb, and to pass in what to generate from the Gradle plugin to the 'jar' version of our generators.
I think in the short term we can use this for some more options. In the longer term, when we might want to record per-service or even per-method options, it becomes interesting to read those from a configuration file much like we added for run-time client options in #151.
We had a discussion whether to put code generation options into protobuf files or to configure things from the outside (i.e. the build plugins in the case of akka-grpc).
The consensus seems to be not to use protobuf options in general because it will increase coupling of protobuf files to a particular code generator. This runs counter to the idea that protobuf files only describe the interface but not how it is used.
Instead, we'll need some infrastructure that allows to configure code generation.
We already have some options in our examples/tests:
https://github.com/akka/akka-grpc/blob/3bf1c5a5afea0b28443f7252a256ea0c9018cdd4/plugin-tester-scala/src/main/proto/echo.proto#L3-L4
Should we try to get rid of those as well?