protoc-gen-tonic: compression feature always on

[barakmich]

First of all, thank you so much for making these -- this is the right way to do protobuf generation across a bigger/multi-language world, as opposed to via Rust's build.rs!

I filed tokio-rs/console#349 over on tokio's console-api because I'm in sort of a catch-22. Because I generated my protos with protoc-gen-tonic, they have the "compression" feature enabled which emits, in the generation, fields that require my library consuming them to have "compression" enabled as well.

That's fine if it's just me, but because console-api has their own generated protos with compression disabled, I get trouble when I try to compile console-subscriber into my application because I've already got tonic and it enables "compression" which breaks their generated protos' expectations.

IMO, they should just have a more general proto committed. But I figured I'd send an issue along in case other folks see it, or to see if there's a convenient way to enable or disable the compression features from the generated tonic files.

[neoeinstein]

This is one that I'll need to bring to tonic too. We may want to make compression disabled here by default, but with compression being a compilation feature, I have a hard time making it into an option.

I have a thought about how I might make that work, so let me see if I can do some dependency magic to make compression optional.

[barakmich]

That'd be fabulous! But yeah, it does seem like it goes to the tonic level too. compression looks like a sort of non-standard feature flag in tonic that explicitly expects you to be generating these things dynamically. Which is bad when you want to pre-generate with other tools 😢

[neoeinstein]

Sadly my dependency hacking wasn’t successful right off, but I may have an angle to get compression out of tonic-build so that the generated code doesn’t care about it, but you can get it or not through the tonic compression flag. May require a SemVer bump in tonic, but should make it so that intermediates can check in generated code without causing this type of breakage (and leave the decision to include the compression machinery to the end application).

[tatemz]

I suppose these compilation errors I get are related? Is there a workaround?

error[E0412]: cannot find type `EnabledCompressionEncodings` in this scope
   --> __generated/proto/rs/schema/src/foobar.services.v1.tonic.rs:556:37
    |
556 |         send_compression_encodings: EnabledCompressionEncodings,
    |                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in this scope

error[E0283]: type annotations needed
   --> __generated/proto/rs/schema/src/foobar.services.v1.tonic.rs:207:47
    |
207 |                 accept_compression_encodings: Default::default(),
    |                                               ^^^^^^^^^^^^^^^^ cannot infer type

[tatemz]

Answering my own question. Turns out this is needed in the app Cargo.toml:

[dependencies.tonic]
version = "0.7.2"
features = ["compression"]