Conversation
xla
left a comment
There was a problem hiding this comment.
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.
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.
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.
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.
Really good to know, let's put your comment into the docuemtnation so others are aware of the limitations.
xla
left a comment
There was a problem hiding this comment.
Wanted to state that I didn't review the generated files in depth.
| @@ -0,0 +1,10 @@ | |||
| #[test] | |||
| pub fn import_evidence_info() { | |||
There was a problem hiding this comment.
What are we asserting with this test?
There was a problem hiding this comment.
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.
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 <a.simmerl@gmail.com>
Co-authored-by: Alexander Simmerl <a.simmerl@gmail.com>
…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. |
xla
left a comment
There was a problem hiding this comment.
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 <greg@informal.systems>"] | ||
| edition = "2018" |
There was a problem hiding this comment.
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.
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.
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.
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.