Package name alteration

[andrewparmet]

I write a protobuf compiler (https://github.com/open-toast/protokt) for the JVM that I want to "play nicely" with grpc-kotlin. Right now I accomplish this by choosing the package of generated classes to match the package that would be chosen by protobuf-java. The grpc-kotlin generator is agnostic as to the implementation of its request and response types, so by generating service descriptors and method descriptors with the right package names, class names, and function names I can "plug and play" into the stubs generated by grpc-kotlin.

This comes with an unfortunate side effect: protokt users cannot also have the protobuf-java generated code on their classpaths due to the inevitable classpath collisions. I'd like to figure out a way to achieve both goals - play nicely with grpc-kotlin and with protobuf-java.

The most promising way I know to alleviate classpath collisions is to mangle package names in a way unique to my generator (e.g. by adding a prefix like protokt. to every package), but then grpc-kotlin won't know how to generate code with the right packages to match.

Another option is to use a file option kotlin_package to specify the Kotlin package of code in a file and teach grpc-kotlin how to use it, but then users won't be able to use third-party types as their request or response types since they won't have that option specified. Maybe that's not such a bad convention, but ideally protokt doesn't dictate it. (As an aside, they already can't use classes from com.google.protobuf for this reason - we have to mangle our versions of those in order to use the protobuf-java runtime.)

Is there an existing mechanism (or could there be one) to handle this sort of use case?

related: https://github.com/open-toast/protokt/issues/173 https://github.com/open-toast/protokt/pull/169

[andrewparmet]

Rather than supporting a new option, an alternative would be to use this code generator as a library and modify our input protos. This would be similar to running it as a plugin but we don't need a self-contained executable.