Problem
crates/fluss/build.rs compiles src/proto/fluss_api.proto with prost-build on every build, which requires a system protoc: prost-build dropped its bundled protoc back in 0.11, and the modern vendored fallbacks (protoc-bin-vendored, protobuf-src) have to be wired up by the build script itself. Every downstream consumer of fluss-rs inherits that system dependency, and so does this repo: seven workflows currently install protoc, release_python.yml alone carries five per-platform install blocks.
fluss_api.proto is a static file that only changes when the wire protocol does, so every builder pays for codegen that never produces anything new. The Java server does not have this problem: it generates its RPC code with its own pure-Java protogen (derived from lightproto), so fluss-rs is the only Fluss component that imposes a system protoc.
We hit this in Apache Iggy while adding a Fluss source connector (apache/iggy#3688): pulling in fluss-rs would force protoc onto every contributor's cargo build.
Proposal
Do what prost-types and arrow-rs already do: check the generated code into the repo and regenerate only when the proto changes.
- commit the prost output as
crates/fluss/src/proto/proto.rs (1,343 lines)
- replace
build.rs with a small gen crate plus a regen.sh, following the arrow-flight layout; prost-build becomes a normal dependency of the gen tool, so building the workspace never invokes protoc, only running the regeneration does
- CI and DEVELOPMENT.md drop the protoc requirement
I have this working locally: the checked-in file is byte-identical to today's build.rs output, and cargo build / cargo clippy --all-targets --workspace -- -D warnings / cargo test (572 passed) / cargo doc all pass on a machine with no protoc installed. PR incoming.
Once merged, a 0.1.1 patch release would let 0.1.0 consumers pick this up without waiting for 0.2.0 (0.2.0 was yanked on release day).
Problem
crates/fluss/build.rscompilessrc/proto/fluss_api.protowith prost-build on every build, which requires a systemprotoc: prost-build dropped its bundled protoc back in 0.11, and the modern vendored fallbacks (protoc-bin-vendored, protobuf-src) have to be wired up by the build script itself. Every downstream consumer offluss-rsinherits that system dependency, and so does this repo: seven workflows currently install protoc,release_python.ymlalone carries five per-platform install blocks.fluss_api.protois a static file that only changes when the wire protocol does, so every builder pays for codegen that never produces anything new. The Java server does not have this problem: it generates its RPC code with its own pure-Java protogen (derived from lightproto), sofluss-rsis the only Fluss component that imposes a system protoc.We hit this in Apache Iggy while adding a Fluss source connector (apache/iggy#3688): pulling in
fluss-rswould force protoc onto every contributor'scargo build.Proposal
Do what prost-types and arrow-rs already do: check the generated code into the repo and regenerate only when the proto changes.
crates/fluss/src/proto/proto.rs(1,343 lines)build.rswith a smallgencrate plus aregen.sh, following the arrow-flight layout; prost-build becomes a normal dependency of the gen tool, so building the workspace never invokes protoc, only running the regeneration doesI have this working locally: the checked-in file is byte-identical to today's
build.rsoutput, andcargo build/cargo clippy --all-targets --workspace -- -D warnings/cargo test(572 passed) /cargo docall pass on a machine with no protoc installed. PR incoming.Once merged, a 0.1.1 patch release would let 0.1.0 consumers pick this up without waiting for 0.2.0 (0.2.0 was yanked on release day).