Support custom options #9
Conversation
|
ping @pseudomuto To support the proto3 custom field option (pseudomuto/protoc-gen-doc#425), there are two tools that need to be modified. The protoc-gen-doc leverages the protokit to create a plugin for the compiler protoc. The protokit gets the proto descriptor files from protoc and applies some necessary process on the proto descriptor, then pass it to proto-gen-doc to let it generate documentation. The reason why the protoc-gen-doc doesn't support proto3 custom field option is that the output of compiler protoc doesn’t include the proper custom field option, to more detail, those options information is saved as byte rows in descriptor files. To display custom field options properly on documentation, we need to
Change on the protokitmaster...sharonliao:protokit:master
Change on the protoc-gen-doc
|
|
Any update of this PR? Really looking forward to having this feature in proto-gen-doc so we could generate custom options in the output... |
|
Ah man, I came looking for this functionality following the thread from pseudomuto/protoc-gen-doc#425 Yes please, I am also looking for custom extensions documented in our descriptorset. |
|
Fails with service method options: |
|
It seems that problem occurs when you have I did manage to make it not crash by changing the types.go file and doing this: func getOptions(options proto.Message) (m map[string]interface{}) {
protoregistry.GlobalTypes.RangeExtensionsByMessage(proto.MessageReflect(options).Descriptor().FullName(),
func(extension protoreflect.ExtensionType) bool {
if m == nil {
m = make(map[string]interface{})
}
m[extension.TypeDescriptor().TextName()] = extension
return true
})
return m
}instead of what it did before. I barely know anything about go or the proto libraries though so I am not sure if this can be done otherwise. I'll publish a fork in a bit. What I noticed is that it behaves differently now and I think this has something to do with registering extensions. Before I'd get "options": {
"google.api.http": {
"rules": [
{
"method": "POST",
"pattern": "/{{system_id}}/group/get",
"body": "*"
}
]
}
}now it changes to "options": {
"[google.api.http]": {
"body": "*",
"post": "/{{system_id}}/system/get"
},
"[ngcp.api.common.routing_key]": "provisioning_service.system.get.{{system_id}}"
}So my custom option is here now, but the HTTP one is different. Funnily enough if I did if strings.Contains(string(fileDescriptor.FullName()), "google.api") {
log.Println("Nah, drop")
return true
}in the |
|
Here's the fork: https://github.com/haljin/protokit Also the thing that makes the whole thing explode is the custom parser in https://github.com/pseudomuto/protoc-gen-doc/blob/master/extensions/google_api_http/google_api_http.go Hopefully someone more clever can make sense of this and get this stuff merged. :) |
ping @pseudomuto
What is Changing?
This PR aims to fix this issue pseudomuto/protoc-gen-doc#425, to support custom, user-defined options exposing.
The custom options are unknown at compile time, so that FileDescriptorSet got from the protoc compiler won’t include the readable custom options info. To expose custom options from unknown fields, we need to register all custom extensions by recursively going through all the proto files, and then marshal and re-unmarshal the descriptor files by using the extensions registered before as a resolver. This step will decode custom field options from byte rows to a readable format.
How is it Changing?
Basically, I followed this issue golang/protobuf#1260 to implement the registering and marshal and re-unmarshal process.
golang/protobuf#1260 (comment)