Tonic: Support creating multiple modules for services rather than just one

Created on 6 Feb 2020  ·  3Comments  ·  Source: hyperium/tonic

Feature Request

Prost will create a module structure from the package specifier in the .protos, from the prost docs:

For example, given the package specifier:

package foo.bar;
All Rust types generated from the file will be in the foo::bar module.

Tonic could do the same, or consume an option on the top-level proto to figure out the module.

Crates

tonic-build

Motivation

Currently, unless you wrap the include_proto! invocation with the appropriate nested modules, the modules don't line up with the prost generated ones:

error[E0433]: failed to resolve: there are too many leading `super` keywords
   --> /Users/danny/googleapis/google/cloud/secrets/tsm/target/debug/build/tsm-c643fd8a748aa3b1/out/google.cloud.secrets.v1beta1.rs:561:60
    |
561 |             request: impl tonic::IntoRequest<super::super::super::super::iam::v1::SetIamPolicyRequest>,
    |                                                            ^^^^^ there are too many leading `super` keywords

Proposal

  • generate modules from service package specifier

Alternatives

  • consume a rust_module option on the grpc .proto and generate code in that module
  • have this be configurable in tonic_build::configure

Most helpful comment

Did some reading; this is a prost-build thing, more than anything. It seems the right way to handle this is to either

a) if it's all within the same crate, provide the module structure around the generated services to match the grpc package structure, or

b) use prost_build::Config::extern_path to instead refer to types in other crates and separate services out that way

Closing this, as it's not a tonic issue.

All 3 comments

Did some reading; this is a prost-build thing, more than anything. It seems the right way to handle this is to either

a) if it's all within the same crate, provide the module structure around the generated services to match the grpc package structure, or

b) use prost_build::Config::extern_path to instead refer to types in other crates and separate services out that way

Closing this, as it's not a tonic issue.

Both those do similar things; for the proto, the leading dot indicates that it's a fully qualified path. For the rust module, it indicates that the path is an absolute path i.e. not relative to the current module.
The original PR might shed some light on it for you.
GitHub notifications@github.com wrote:
“I notice you made a repo where you tested this and you included code along the lines of:

tonic_build::configure().extern_path(".uuid", "::uuid")

Are you able to explain what this does exactly? I'm new to Rust and I did something similar and it solved this issue for me as well, but I actually have no idea how/why.

For example, what's the significance of the preceding . in the proto path, and then the :: in the rust path?

Please forgive me if this is an extremely noob question! :(”


You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or unsubscribe.

Honestly, I don't remember but ::uuid was the old way of picking up root paths where now you can do crate or just call the crate name directly.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

frol picture frol  ·  7Comments

LucioFranco picture LucioFranco  ·  6Comments

LucioFranco picture LucioFranco  ·  7Comments

petratbtl picture petratbtl  ·  7Comments

rlabrecque picture rlabrecque  ·  5Comments