Every crate should expose all the types necessary to use it. Obviously. Below is a long dumb story of how things go wrong when you break this rule, but the bottom line is, code generated by twirp-build should re-export twirp::Client, which is needed to use the generated traits and impls.
I had a problem recently trying to upgrade a large workspace from reqwest 0.11 to reqwest 0.12.
The workspace has a dependency (maintained by another team) using twirp-rs to generate client bindings. I ended up with this dependency graph:
Cargo can handle this fine; it builds and links two versions of twirp (and reqwest), but that's OK for the short term and it helps to work incrementally.
However, the way couture uses hats-client is by creating a twirp::Client. This doesn't work because the twirp::Client that couture is using is not the same type as the one hats-client is using. It's a different version. If I could have said hats_client::Client::builder(), we would have been in business.
Every crate should expose all the types necessary to use it. Obviously. Below is a long dumb story of how things go wrong when you break this rule, but the bottom line is, code generated by
twirp-buildshould re-exporttwirp::Client, which is needed to use the generated traits and impls.I had a problem recently trying to upgrade a large workspace from
reqwest 0.11toreqwest 0.12.The workspace has a dependency (maintained by another team) using twirp-rs to generate client bindings. I ended up with this dependency graph:
Cargo can handle this fine; it builds and links two versions of twirp (and reqwest), but that's OK for the short term and it helps to work incrementally.
However, the way
coutureuseshats-clientis by creating atwirp::Client. This doesn't work because thetwirp::Clientthatcoutureis using is not the same type as the onehats-clientis using. It's a different version. If I could have saidhats_client::Client::builder(), we would have been in business.