proto source traceability ask #419
Description
Hey all from grpc-reflection
We use the generated metadata and descriptors from this project to enable reflection of grpc services, but we have a problematic corner case:
GRPC supports circular recursive structures, where A contains B and B contains A, but this is only valid if both messages are defined in the same .proto file. This is a problem for us, as once the proto files are compiled, the organizational relations between the modules and their source files is no longer guaranteed. The option one_file_per_module=true would complicate this further.
Reflection has been operating by assuming each message came from its own proto file and ignoring the actual source organization (a hack), which works outside of the aforementioned case. If we knew which proto file a message or service definition came from, we could reflect them in their original organization.
Ask:
- Can we include the source proto filename when generating the Service and Message definitions?
Pros:
- Reflection can consume and use this data directly
- traceability improvement mapping modules back to their prototype sources
Cons:
- I don't know if the proto names/paths are sanitized, we do not want to embed local filesystem info into compiled modules and potentially leak any info from the engineers' workstation.
I did make an attempt at this here, where Service and Message modules are generated with a function __proto_source__/0 that returns the file descriptor name from the protocol call.