collectiveidea / protoc-gen-twirp_ruby Goto Github PK

Introduce an option, something like generate=<service|client|both>, to configure what code the plugin should generate.

• generate=service - only generate the ::Twirp::Service subclass.
• generate=client - only generate the ::Twirp::Client subclass.
• generate=both - generate both. Default option for backwards compatibility (and current behavior).

For generate=client, we don't want to use the client_for DSL because we do not have a service class reference to pass in (because one was not generated). Instead, we'll need to configure the client "manually".

protoc supports the ruby_package option in proto files to specify the module of the generated ruby code (see protocolbuffers/protobuf#4627).

The twirp generator should also respect the ruby_package option if present, and prefer that over the proto file's package.

To implement this, we'll likely want to build up a type mapping for the proto file and all of the proto file imports (where the imports might also leverage ruby_package), rather than naive approach we took in our initial convert_to_ruby_type at https://github.com/collectiveidea/protoc-gen-twirp_ruby/blob/v1.0.0/lib/twirp/protoc_plugin/code_generator.rb#L145

Reproducing comments from #15:

We need to pass both example.proto and package/actions/asks.proto when calling protoc --ruby_out in order to generate the ruby code for the messages in both proto files. However, when we add the --twirp_ruby_out option to invoke our gem plugin, we end up generating an empty scaffolding twirp file for the asks.proto file with no services defined.

On one hand, this is expected behavior. Per the docs, the code generator should generate code for the proto files explicitly listed on the command line.

On the other hand, do end users expect empty twirp files when no services are defined? Generating empty scaffolding files doesn't seem helpful.

I'm leaning towards introducing a future option to skip generation when the proto file contains no services. I think the default behavior should be to continue to generate empty twirp files per the doc guidance, but we can allow callers to opt-in to change that behavior.

Another option would be to do nothing and force callers to invoke protoc twice, splitting up the ruby generation and the twirp generation, e.g.:

1. Generate ruby definitions for all inputs: protoc --proto_path=./spec/fixtures/import_type_retention --ruby_out=./spec/fixtures/import_type_retention example.proto package/actions/asks.proto

2. Generate twirp definitions only for example service: protoc --proto_path=./spec/fixtures/import_type_retention --twirp_ruby_out=./spec/fixtures/import_type_retention example.proto

Let's introduce an option, something like --twirp_ruby_opt=skip-empty, in order to avoid generating twirp files that are just empty scaffolding for proto files passed to protoc that do not contain any service definitions.

That'll allow both ruby and twirp generation from a single call to protoc.