rust-protobuf icon indicating copy to clipboard operation
rust-protobuf copied to clipboard

How to import proto file in different packages with same name?

Open BusyJay opened this issue 7 years ago • 5 comments

Consider following case:

A/n.proto defines a TestA message, and B/n.proto defines a TestB message. When import B/n.proto into A/m.proto, and use TestB, generated sources always import TestB via super::n::TestB. However, super::n is A/n.proto, which doesn't contain TestB, hence lead to compilation error.

Related to #189.

BusyJay avatar Dec 08 '17 14:12 BusyJay

+1. I run into the same error. I think using super:: in generate files is always wrong, instead fully qualified names should be used. I.e. if

package foo.blah.blub; 

import "B.proto"; // contains package muh.mah.me;

the references should always be to ::muh::mah::meh::Message instead as to super::me::Message.

SirVer avatar Jan 12 '18 14:01 SirVer

+1 Is there any preferable workaround for this issue?

I also have this problem when importing google.api types which i'm building in its own module namespace;

 package foo.bar; // located in src/foo/bar.protos

  message Response {
    google.rpc.Status status = 0;   // located in src/google/rpc/status.proto
  } 

The rust code generated by protoc for foo.bar package trys to use super::status::Status which will result in an compilation error (because the type is located in protos::google::rpc::status::Status)

ruuns avatar Dec 09 '18 12:12 ruuns

It would appear this is still a problem. Included protos should not use super:: at the top level. This irreparably breaks the generated code.

thavlik avatar Feb 20 '19 15:02 thavlik

I'm facing the same issue and I agree that using absolute references would be better than using super::.

In case of (for example) Go, it is possible to annotate Protobuf files with an option go_package defining the import path. This also solves the case when different Protobuf files are split across multiple (Go) packages. E.g. when using the "well known" Timestamp type, it will automatically import this definition from github.com/golang/protobuf/ptypes/timestamp. This import-path defined here: https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/timestamp.proto#L37.

When generating Rust code, the Timestamp is of type ::protobuf::well_known_types::Timestamp. I guess the mapping of "well known types" is kept in the Rust Protobuf compiler source. Maybe an option rust_package could 1) make these imports more explicit 2) solve the issue of the super:: imports as it allows users to explicitly define how types within a Protobuf file must be imported. (in case of the timestamp.proto it could have an option rust_package = "protobuf::well_known_types").

brocaar avatar Dec 13 '19 15:12 brocaar

Issue still exists. As a workaround, I'm post-processing generated rust to replace all super:: with an absolute crate::.... It's certainly not ideal, but it does work.

cilki avatar Apr 25 '21 15:04 cilki