Imports are confusing

I have a gRPC client that is trying to import a service and no matter what I try it does not get around the problem. Seems that importing for gRPC has some hidden naming rules which are not spelled out in the example I have seen.

 cargo build
   Compiling client v0.1.0 (/Users/bihaber/projects/rust/helloworld/helloworld/client)
error[E0432]: unresolved import `self::IMService::IMService_client`
 --> src/
3 | use self::IMService::{HelloRequest, IMService_client::HelloClient};
  |                                     ^^^^^^^^^^^^^^^^ could not find `IMService_client` in `IMService`

For more information about this error, try `rustc --explain E0432`.
error: could not compile `client` (bin "client") due to previous error

Protobuf look like -

syntax = "proto3";
package hello;

// The greeting service definition.
service IMService {
  // This is the description for the grpc SayHello Greeter Service. This takes in a HelloRequest as message and returns
  // a HelloReply greeting message. Used to Send a greeting.
  rpc SayHello (HelloRequest) returns (HelloReply) {}

// The request message containing the user's name.
message HelloRequest {
  // This is the description for the name attribute of the HelloRequest message.
  string name = 1;
  string pass = 2;

// The response message containing the greetings
message HelloReply {
  // This is the description for the message attribute of the HelloReply message.
  string message = 1;
  string token = 2;

Assuming you’re using the tonic crate to do this, it looks like the submodule name is generated by this function, so you’re probably looking for something like this:

use self::IMService::i_m_service_client::IMServiceClient;

Simplifying down to just the problematic import, we have:

use self::IMService::IMService_client::HelloClient;

This appears in src/ self in this context is the top-level module for the crate - the module defined either by if this is a library crate, or by if this is a binary crate, assuming Cargo's defaults apply.

That means that, for this import to resolve, that crate needs to contain a namespace named IMService (probably as a module), which in turn needs to contain an IMService_client namespace (ditto), which in turn exposes a symbol HelloClient. The error points to that second step: IMService does exists, but whatever it is, it doesn't contain IMService_client.

If these are all expected to be modules, where is IMService defined?

If the answer is "mod IMService; in or in," does the file src/ exist?

If the answer to the above is yes, does that file include a declaration for the symbol IMService_client (for example via a mod or pub use statement, or by defining a type, function, trait, or similar)?

1 Like

There is no src/ Everything is in the src/ I suspect there is a naming issue with gRPC. I have tried many ways to get around the problem and the only thing that seems to work is making everything a single word in lower case. But other problems prevent the program from working.

Error: Status { code: Unimplemented, message: "Method not found: imserver.imserver/hello", metadata: MetadataMap { headers: {"content-type": "application/grpc"} }, source: None }
And yes I had to jerk around the names to get it to build and run. This error doesn't make sense as everything matches the proto.

as everything matches the proto.

i haven't used tonic or gRPC in Rust, but i have tiny experience with gRPC in python.

I assume process is similar to other languages -> so your protofile with name XXX.proto should "translate" to a newly generated (plus some naming case conversions possibly) after bubbling through tonic_build crate as part of a build process? Is my assumption that XXX = "IMService_client" correct?

could be hard to narrow down problem as we dont know wheter/how you deviated for standard workflow...
assuming you cannot share full project on online repo, maybe try adding here:

  • output of tree bash command - to show project structure of relevant files, primarily including

    • location of .proto
    • file that has problematic "uses" statement
    • whole chain of parent modules/folders up to cargo root directory
  • steps that you had to take in so called jerking and maybe an error tha lead you to it