tokio-rs / prost

PROST! a Protocol Buffers implementation for the Rust Language
Apache License 2.0
3.92k stars 504 forks source link

`enable_type_names` fails for multiple proto files with the same package name. Is this expected? #946

Closed BKDaugherty closed 11 months ago

BKDaugherty commented 11 months ago

It's possible I'm using protobuf files incorrectly, but I work at a company where we have a bunch of protobuf files that are specified like so...

brendondaugherty@C6W2M6LRF4 prost_playground % tree proto
proto
└── my_company
    └── example
        ├── example.proto
        └── example2.proto

3 directories, 2 files

Where each file in example declares the package my_company.example

example.proto

syntax = "proto3";
package my_company.example;

message MyMessage {
  uint32 some_other_field = 1;
}

example2.proto

syntax = "proto3";
package my_company.example;

message MyOtherMessageInTheSamePackage {
  uint32 some_other_field = 1;
}

We are trying to do some reflection recently, and we were super stoked to see prost::Name come to prost 0.12. However we noticed when trying to enable it that our package layout didn't seem to be supported, as we were getting a const PACKAGE declaration for each proto file we had in the generated rust file.

Our build.rs looks like the following:

fn main() -> Result<(), Box<dyn std::error::Error>> {
   let files = [
       "proto/my_company/example/example.proto",
       "proto/my_company/example/example2.proto",
   ];
    let mut config = prost_build::Config::new();
    config.enable_type_names();
    tonic_build::configure()
    .compile_with_config(config, &files, &["./"])?;
    Ok(())
}

Our lib.rs looks like the following

pub mod generated {
    include!(concat!(env!("OUT_DIR"), "/my_company.example.rs"));
}

Using the above build.rs script and lib.rs, we get the following errors.

brendondaugherty@C6W2M6LRF4 prost_playground % cargo build
   Compiling prost_playground v0.1.0 (/Users/brendondaugherty/dev/prost_playground)
error[E0428]: the name `PACKAGE` is defined multiple times
  --> /Users/brendondaugherty/dev/prost_playground/target/debug/build/prost_playground-0d5990a133705fba/out/my_company.example.rs:12:1
   |
1  | const PACKAGE: &str = "my_company.example";
   | ------------------------------------------- previous definition of the value `PACKAGE` here
...
12 | const PACKAGE: &str = "my_company.example";
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `PACKAGE` redefined here
   |
   = note: `PACKAGE` must be defined only once in the value namespace of this module

For more information about this error, try `rustc --explain E0428`.
error: could not compile `prost_playground` (lib) due to previous error

Is this expected behavior? Is there anything we can configure to get around this?

Here's the Cargo.toml I used

[package]
name = "prost_playground"
version = "0.1.0"
edition = "2021"

[build-dependencies]
prost-build = {version = "0.12.0"}
tonic-build = "0.10"

[dependencies]
prost = "0.12"
prost-derive = "0.12.0"
tonic-types = "0.10"
tonic = "0.10"
BKDaugherty commented 11 months ago

Ah. Looks like the fix is here: https://github.com/tokio-rs/prost/pull/944?

Patched my Cargo.toml with that branch, and changed my build.rs so I wasn't using tonic-build, and confirmed that that pull request fixes this for us!

brendondaugherty@C6W2M6LRF4 prost_playground % cat Cargo.toml
[package]
name = "prost_playground"
version = "0.1.0"
edition = "2021"

[build-dependencies]
prost-build = {path = "../tinrab_prost/prost-build"}
# prost-build = "0.12"
tonic-build = "0.10"

[dependencies]
prost = "0.12"
prost-derive = "0.12.0"
tonic-types = "0.10"
tonic = "0.10"

build.rs

fn main() -> Result<(), Box<dyn std::error::Error>> {
   let files = [
       "proto/my_company/example/example.proto",
       "proto/my_company/example/example2.proto",
   ];
    let mut config = prost_build::Config::new();
    config.enable_type_names();
    config
        .compile_protos(&files, &["./"])?;
    Ok(())
}
brendondaugherty@C6W2M6LRF4 prost_playground % cargo build
    Finished dev [unoptimized + debuginfo] target(s) in 0.07s
brendondaugherty@C6W2M6LRF4 prost_playground %
BKDaugherty commented 11 months ago

This was fixed by #944