grpc/grpc-swift

GRPCSwiftPlugin should support adding ReflectionData=true to protocArgs

toffaletti opened this issue · 3 comments

Is your feature request related to a problem? Please describe it.

https://swiftpackageindex.com/grpc/grpc-swift/1.21.1/documentation/grpcreflectionservice/reflectionservicetutorial

following this tutorial, requires running protoc manually instead of using GRPCSwiftPlugin.

Describe the solution you'd like

GRPCSwiftPlugin should have an option for generating ReflectionData similar to these options:

    if let generateServerCode = invocation.server {
      protocArgs.append("--grpc-swift_opt=Server=\(generateServerCode)")
    }

    if let generateClientCode = invocation.client {
      protocArgs.append("--grpc-swift_opt=Client=\(generateClientCode)")
    }

To eventually invoke protoc with these arguments as specified in the tutorial:

--grpc-swift_opt=Client=false,Server=false,ReflectionData=true \

Describe alternatives you've considered

No other considerations, this seems like an oversight in GRPCSwiftPlugin not following protoc-gen-grpc-swift.

Additional context

The tutorial should probably be updated as well to provide the option of using the SwiftPM plugin.

This is probably a different feature request, but it seems like the ReflectionData option should allow for the serialized FileDescriptorSet to be included in the generated Swift code itself so the reflection service can be initialized from a static data part of the binary instead of needing to read a file at runtime? iirc, the Go code generation does this

Thanks for filing this Jason. It's not an oversight, build plugins add files to the build graph and as the generated reflection data isn't Swift code it doesn't make sense to have an option in the plugin. Build plugins also don't provide a stable output directory so we can't easily find them at runtime either.

This is a bit of an unfortunate limitation and makes reflection harder to use. However, we're not opposed to adding an option to embed the reflection data into the generated code, it just requires a bit more thought as we'd need to deal with transitive dependencies so we potentially end up with a lot of duplication.

Thanks for filing this Jason. It's not an oversight, build plugins add files to the build graph and as the generated reflection data isn't Swift code it doesn't make sense to have an option in the plugin. Build plugins also don't provide a stable output directory so we can't easily find them at runtime either.

I was wrong about this: non-Swift code can be added to the Bundle which means this is possible to do from a SwiftPM plugin which was done in #1835.