andrewhickman
Bundling of protobuf sources
I want to ask how coupled is the project to the protobuf source files, and is there an automation of how often this is updated? Do you have a note of what protobuf version is the submodule pointing to?
This project includes some of the .proto files from the google protobuf library, so that well-known protobuf definitions like Any are always available. This is similar to how these files are bundled with protoc.
It looks like the version is currently just a random commit from the time I originally added that submodule, which isn't great. It should definitely match an actual protobuf release, either the latest or chosen to match the version that the prost-types library was generated from.
Pinning to a specific tag would help. I believe renovatebot (maybe also dependabot) have a mode to track submodules via tags.
Also the separation of the proto files to a different crate would also be appreciated, if it can also use local proto files from the system. That would be helpful for the Fedora packaging. Although I am not familiar enough with the ecosystem to judge if bundling or using system files is preferred and what would be the downside of each.
I was thinking more that people might want to opt out of the proto files entirely, if they don't need to reference any of the builtin types. If people have access to the proto files from the system, they can probably just use protoc
In the latest release the proto files are no longer distributed in this package at all. Instead the file descriptor comes from the rust definition in https://github.com/andrewhickman/prost-reflect/blob/6d9e8cb55badc95f802610183b59bff585f6e7bf/prost-reflect/src/reflect/wkt.rs#L21
A better process for managing these descriptors is tracked by #171
That sounds awesome. I will have to thinker around with atuin to see what that entails, but I think we can close this issue with that. Afaiu the linked issue is just about documentation?