-
Notifications
You must be signed in to change notification settings - Fork 25
cardano-rpc | Use buf for code generation instead of cabal/protoc integration #963
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
Conversation
bc8bd6c to
13545dc
Compare
17204ad to
9b3cfa7
Compare
a83e983 to
f256847
Compare
f256847 to
415f396
Compare
Jimbo4350
left a comment
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.
LGTM. You need to fix CI and can you include some brief documentation as to how the files are generated using buf?
f02fa51 to
188cd53
Compare
| plugins: | ||
| # node | ||
| # - plugin: es | ||
| # out: gen/node/src |
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.
Why is this commented out?
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 wanted to enable javascript code generation in a separate PR, since it will touch the cardano-wasm and the grpc integration there.
188cd53 to
935cd80
Compare
935cd80 to
3b339df
Compare
Changelog
Context
Current state
In the previous version of
cardano-rpcpackage, the code was generated during cabal-build which was prolonging build process and was pullingproto-lens-protocinto the dependency tree. This was prone to breakage and was causing complicated issues with cabal's dependency resolution.The proposed solution
This PR changes that by using an external tool buf which allows to generate code from protobuf definitions for various languages. This should be extended for typescript/javascript code generation later.
The caveat here is that it includes generated files in the repository which have following effects:
The end goal is to not use generated code in the production code (or minimal amount of it), and rely on the packages provided by utxorpc:
The ultimate purpose of keeping the generated code in the repository is the ease of work on proto files when one would like to introduce changes to proto definitions without having to go through utxorpc upstream, which is a time consuming process.
Alternatives
An alternative is to move the generated code using
bufto a separate repository. The separate repository would be integrated by SRP only when it's needed.Pros
More separation, smaller diffs. We would only have to rely on SRP for the period of working on new changes to proto files.
Cons
More detached work, changes to proto files less visible. Process of updating a separate repo is more time consuming.
Checklist