cosmos-rust
cosmos-rust copied to clipboard
cosmos
Generate tendermint-proto locally
This PR introduces a series of changes that removes the tendermint-proto dependency and instead generates the tendermint proto files locally using the existing convention of adding a git submodule and handling code to the proto generator crate.
The newly generated tendermint protos are both used for the cosmos-sdk protos and exported for use downstream. Allowing potential consumers of this crate to also drop tendermint-proto dependencies if they currently have one.
The purpose of this change is primarily to provide access to grpc endpoints that tendermint-proto does not.
Generating the tendermint proto files with tonic is non-trivial to do correctly, since tonic and prost will both overwrite each others files and due to the proto file structure of the tendermint repository we can't simply pick one set. Tonic will produce empty files if there are no grpc definitions and prost will of course not generate any grpc endpoints.
The solution for this is to rename specific files in the working directory during proto generation to avoid clobbering them.
Note that the clippy CI test fails, some of the generated proto code is creating clippy warnings (enum size variance) we should decide if it's better to disable clippy for generated files or edit in an exception to the generated files, much like we're already fixing that Validators enum/struct name conflict.
The purpose of this change is primarily to provide access to grpc endpoints that tendermint-proto does not.
Is there an upstream tracking issue for this? Seems like a proper fix would be in tendermint-proto /cc @thanethomson
Otherwise I guess this is OK? It's unfortunate to duplicate the types, but I'm not sure where that would actually pose an issue in practice aside from someone manually constructing protobufs and expecting types from the two crates to interoperate.
As a note this is on hold while we see how useful these endpoints actually are. The GRPC queries seem correct but accesing them via a cosmos-sdk node has proven more non-trivial than we originally expected. So this may not be very useful to carry in this repo until upstream changes are made.