Parsing protoc plugin option containing ',' about protobuf HOT 5 CLOSED

My first recommendation is that you replace , with something else in your generator parameters.

Failing that, yes, I recommend that you parse the CodeGeneratorRequest.Parameters yourself.

(As a distant third, I recommend that you find the protoc maintainers and get them to add a repeated field to CodeGeneratorRequest containing the individual parameters.) (I am not actually recommending this.) (It would be nice, though.)

from protobuf.

Thanks for filing this feature request.

To summarize the different alternatives from my point of view:

1. We build a parser that supports escaping of the ',' so that values (or even keys) can contain ','.
2. We add an overwrite option for users to provide a custom parser. This could be as simple as func (string) []KeyValuePairs where KeyValuePairs is just a pair of strings.
3. Users could encode their parameters with something that doesn't contain ',' (e.g. base64) before passing it to protoc and decode it when their callback is invoked.

Solution 1. requires us to define the exact grammer for escaping and add the implementation (which is 175 lines in the prototype change).

Solution 3. doesn't require any changes but is suboptimal to use and certainly works around a limitation in the protogen package).

Solution 2. requires a very small change to the protogen but adds another public API.

I would like to get @neild feedback on this as well.

from protobuf.

I believe the behavior of separating options with a comma comes from protoc: If you pass --go_opt=a --go_opt=b, protoc passes a CodeGeneratorRequest.parameter of a,b. No quoting or escaping, it just joins all --*_opt params with a comma; see https://github.com/protocolbuffers/protobuf/blob/main/src/google/protobuf/compiler/command_line_interface.cc#L2393.

As such, I think the right thing to do is accept that commas are not valid in option values.

If you do need some different behavior, then you can always modify the CodeGeneratorRequest before passing it to protogen.Options.New. (This requires that you use New rather than Run, but Run isn't all that complicated.)

from protobuf.

@neild if I understand correctly, what you are recommending is parsing the CodeGeneratorRequest.Parameters and quoting/escaping it. Basically, duplicating the protogen.Options.run logic in our own plugin. Am I getting this right?

from protobuf.

Closing this issue for now. Feel free to reopen if you have further input or questions.

from protobuf.