include_proto only imports main proto file about tonic

[LucioFranco]

@Mathspy hi! Thank you for the kind words! <3

So I actually think this comes down to the fact that each proto is in their own package. So prost-build will build one rs file per package. Generally in protobuf if you have folder structure like proto/helloworld/...proto all protos within this folder are under the helloworld package. So to fix your problems here change hello.proto to:

syntax = "proto3";
package helloworld;

// The request message containing the user's name.
message HelloRequest {
  string name = 1;
}

// The response message containing the greetings
message HelloReply {
  string message = 1;
}

This will generate the messages and the service within the same rs file.

[ssankko]

I encoutered similar problem and wrote a little proc-macro to deal with it.
https://crates.io/crates/tonic_include_protos
It will import all generated files and put it into corresponding mod structure.
I guess i leave it here for someone in the future not to struggle.

[Mathspy]

Oh sweet! This actually does work really well, thank you! It seems to have an edge case when there are several ENUMs with similarly named variants like:

enum EnumTypeThing {
    HELLO = 0;
    NAME = 1;
}

and

enum EnumTypeThingInDifferentFile {
    NAME = 0;
    FILE = 1;
}

This would lead to an error during build like:

"protoc failed: file1.proto:9:5: \"helloworld.NAME\" is already defined in file \"hello.proto\".\nhelloworld.proto:9:5: Note that enum values use C++ scoping rules, meaning that enum values are siblings of their type, not children of it.  Therefore, \"NAME\" must be unique within \"helloworld\", not just within \"EnumTypeThing\"

So I guess that makes this solution not work in this one edge case but in my use case it works so I will leave it up to you to leave the issue open to keep track of that or close it! ❤️

[JohnDoneth]

One way to make the conflicting enum variants work would be to prefix them.

enum EnumType1 {
    ENUM_TYPE_1_HELLO = 0;
    ENUM_TYPE_1_NAME = 1;
}
enum EnumType2 {
    ENUM_TYPE_2_HELLO = 0;
    ENUM_TYPE_2_NAME = 1;
}

Another way would be to nest your enums in messages. This causes them to be put into their own "namespace". With Tonic this causes the generated enums to be put into their own Rust modules. enum_type_thing::EnumTypeThing, and enum_type_thing_in_different_file::EnumTypeThingInDifferentFile.

message EnumTypeThing {
  enum EnumTypeThing {
    HELLO = 0;
    NAME = 1;
  }
}

message EnumTypeThingInDifferentFile {
  enum EnumTypeThingInDifferentFile {
      NAME = 0;
      FILE = 1;
  }
}

[blittable]

There will be some who don't want to adjust protobuf files - as they are often interfaces for other languages. That fact, and some of the challenges around what Prost generates (especially Option predictability) - is there a way to decouple the the 'models' from the client/server impls?

[LucioFranco]

@blittable could you explain more what you mean by decoupling the models?

[blittable]

@LucioFranco
I was mocking up a food ordering system, so I had types like Order, Delivery, etc. and ended up adjusting some namespaces to fit the client/server generation code. That would be sub-optimal if I had other clients (iOS, Android) dependent on those. But, that might be my inexperience with the pf namespaces and imports, so I'll try to demonstrate and write it up if it's still problematic.

Likewise, it might be my inexperience with protoc, but I wish I could use my .rs code as inputs to tonic. I'm adjusting an interface to fit the tool (option types, namespaces, etc.) and then (hypothetically) telling other clients (e.g. iOS) to accommodate.

[LucioFranco]

@blittable agreed, I will think about it a bit.