-
Notifications
You must be signed in to change notification settings - Fork 231
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proto: bootstrap crate #508
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Extra dope! Bunch of questions inline.
I also wonder, if the proto-compiler
needs to be its own crate, wouldn't it suffice that it lives as a bin
in the proto crate? It would spare some overhead.
In the generated files, do we depend on the tendermint.
prefix? It strikes me as odd and doesn't really add any value, maybe worth looking into dropping those.
tendermint-proto/compiler/build.rs
Outdated
// Assume that the tendermint Go repository was cloned into the current repository's | ||
// target/tendermint folder. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As tendermint is an public repository, can't the build.rs
do the checkout. Would reduce some overhead and souce of errors.
@@ -0,0 +1,36 @@ | |||
use std::fs::remove_dir_all; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As the compiler is run on demand and not included as a dependency, do we need the extra build.rs
or can we consolidate them in here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried, but the prost-build
crate is weird: it expects to run during build, then it emits an OUT_DIR
env.var which is only available during execution.
Hence, I have no choice but to do the actual translation during build and the move during execution.
The OUT_DIR
is a variable that contains a temp.path within the target
folder. Normally, prost-build
expects you to build the proto files during each build process and include them during the execution with this OUT_DIR
env.var.
Instead we copy the files into another crate, the proto
crate, so IDEs have an easier time identifying what's what. And it doesn't make sense for us to rebuild the proto files with each build.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really good to know, let's put your comment into the docuemtnation so others are aware of the limitations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wanted to state that I didn't review the generated files in depth.
tendermint-proto/tests/unit.rs
Outdated
@@ -0,0 +1,10 @@ | |||
#[test] | |||
pub fn import_evidence_info() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are we asserting with this test?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just didn't want to submit the generated files with no test at all. It's a weak try at "at least do something" with the generated structs.
We can either implement decvent tests for all structs or completely remove testing the automated structs. I'm not sure what's the best way of dealing with it, so this is a reminder to discuss it. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd ditch this test and capture a follow-up issue or inform an existing which already tracks testing. The challenge here is to find the right level of granularity. As this mostly around serialisation it might make more sense to test it indirectly through other means.
Co-authored-by: Alexander Simmerl <[email protected]>
Co-authored-by: Alexander Simmerl <[email protected]>
…int-rs into greg/proto-crate
All comments addressed and apart from the last one about testing the automatically generated structs, all of them are fixed or a reason given why we can't really do much about it. Please do another sweep and let's see if there are other things we need to discuss. |
Codecov Report
@@ Coverage Diff @@
## master #508 +/- ##
========================================
- Coverage 30.7% 26.6% -4.2%
========================================
Files 140 150 +10
Lines 6181 6106 -75
Branches 2051 2001 -50
========================================
- Hits 1901 1627 -274
- Misses 2886 3427 +541
+ Partials 1394 1052 -342
Continue to review full report at Codecov.
|
Could the generated files be added to codecov ignore section. These generated files should not be included in the code coverage |
not sure if this was answered but this is from the |
Aren't we doing a manual copy step where we could force the omission of the prefix? @greg-szabo |
Hey guys! Apologies for the late reply, I was busy today. I forgot to address the two notes Xla had at the beginning of his review. (Or end or whatever, the one that was not inline.) So, we could start renaming the files but I don't really see the benefit. The file names follow the directory layout in the Tendermint repo. To be honest, we could suggest getting rid of the tendermint folder in that repo under the Additionally, I don't export the tendermint folder in the path, I use So, I think it's overoptimizing. If you guys still think it's worth doing it, just make a note here and I'll get it done. The other note I forgot to address was about the So, would you want me to move it under |
I've excluded the generated files from codecov, as requested by Marko. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your rationale is super sound and I don't think we need to optimise any of the new structure. Let's see how it plays out and if we run into limitations. Great work!
🌸
Why was this renamed?
I think the file |
name = "tendermint-proto-compiler" | ||
version = "0.1.0" | ||
authors = ["Greg Szabo <[email protected]>"] | ||
edition = "2018" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be good to explicitly mention that this is not meant to be published (yet) via: https://doc.rust-lang.org/cargo/reference/manifest.html#the-publish-field
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Opened an issue for that, good point.
* `git clone https://github.com/tendermint/tendermint` into the repository `target/` folder. | ||
* `cargo run` in the compiler folder. | ||
|
||
The resultant structs will be created in the `tendermint-proto/src/prost` folder. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wasn't the folder renamed from tendermint-proto to proto? Would be good to double check if the above still makes sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, good point. Opened a quick issue about it.
The example file was renamed accidentally, I've opened an issue about it to fix it. |
First step of #504 - creates Rust structs from Tendermint proto files.