Generating code via a binary about prost

[sercand]

@danburkert prost-build might be superior but when dealing with other languages like go and javascript we use protoc to generate code more than one language. Adding another language is just adding one line script. For prost, we have to carry proto files so we can generate source code. The approach at https://github.com/pingcap/kvproto, which is a single repo for go and rust, could not work for prost.

[thijsc]

Thanks for thoughtful reply!

There are some upsides we might miss out on: It can be nice to look at the generated code and if the Rust file is in the project less-fancy editors like vim can still do autocompletion on the protobuf structs. This might be less of an issue with this crate since there are not getters and setters.

I will try it out and will let you know how it works out in our project.

[sercand]

@danburkert Because we need the proto files and protoc at build-time and I don't like distributing proto files. Pre-generating solves the problem missing proto files and protoc on the device. For example, I use Raspberry PI to build some projects and it seems that prost-build cannot download Linux arm64 protoc binary so I can't generate proto files on Raspberry PI.

[danburkert]

There actually used to be a protoc plugin ,protoc-gen-prost, but it got removed in 0529321. It could be added back somewhat easily, but I really think the prost-build approach is superior in most respects. I'm a big believer in build-time generation, since it's fast, easier to configure (code vs env opts), and makes the build more reproducible in most situations.

I do sympathize with the external .proto issue, though. That's actually the situation I'm in with the project which motivated building prost. I'm currently solving it by downloading the required .protos at build time (see this example). I find this an acceptable practice, but I imagine downloading things during a build (even when cached) can turn people off. It's always an option to just copy the .protos into the project.

[danburkert]

If you need to look at the generated code, you can find it in target/debug/build/<crate-name>-<random-digits>/out/, and cargo-expand can be used to see the expansion of derive(Message. The auto-complete issue is interesting, I'm not sure whether racer et al can 'see through' the include! trick.

[danburkert]

Going to close this out, but feel free to re-open if you still feel like a protoc plugin would be helpful.

[danburkert]

@sercand I'm not seeing why the prost approach couldn't work for such a repo. Couldn't you just remove the pre-generated .rs files and add a build.rs which generates them at build-time?

[abreis]

I have a couple issues with the current approach:

• To have a look at the generated code, I have to go fish around target/ for *.rs files. And for some reason, there are usually 3-4 folders and only one of them has the up-to-date schemas, e.g.:

target/debug/build/sometool-25a8aa2698a97ed5/out/api.rs
target/debug/build/sometool-4029fb7b227cd879/out/api.rs
target/debug/build/sometool-69de7112f213c302/out/api.rs
target/debug/build/sometool-a32f6a50bd8eb3e2/out/api.rs

• Also because of this, IntelliJ IDEA doesn't see the compiled schemas, and I get no autocompletion in its editor.

If anyone here has found a way around these, I'd love to hear from you.

[dgmneto]

@abreis, I'm having the exact same issue with VS Code. I think I understand why to generate the files this way, but I feel it's not very straight forward to work with them like that.
I'd be glad to hear if anyone found a better way around this