Using third-party .proto files with proto-rust-grpc

help
1

For $DAYJOB, we're writing a number of microservices in Golang, using gRPC and Protobuf.

Although I like Golang, I also like the look of Rust, and I want to try out making a Rust version of our microservices. For now, I'm using the article Building gRPC Services in Go and Rust | by Kevin Hoffman | Medium as a basis for what I'm doing (since I don't yet understand the moving parts enough to figure it out from scratch).

I've adapted the source code from there so that the build.rs file points to my own .proto file, but it won't compile because of an import line:

import "google/api/annotations.proto";

That .proto file is pulled in from a vendored repo located at https://github.com/googleapis/googleapis, which I added to my Cargo.toml file:

[build-dependencies]
protoc-rust-grpc = "0.2.1"
googleapis = { git = "https://github.com/googleapis/googleapis.git" }

Unfortunately, Cargo doesn't like it:

$ cargo build
Updating git repository *****googleapis/googleapis.git
error: failed to load source for a dependency on `googleapis`

Caused by:
  Unable to update *****googleapis/googleapis.git

Caused by:
  Could not find Cargo.toml in /Users/steve/.cargo/git/checkouts/googleapis-a7f621c154b81d93/62273f2

Is there any way to work around a repository not having a Cargo.toml file? Am I trying something that is likely to never work, or is there another way for me to resolve this (other than simply copying the necessary files straight into my project, which would work but feels inelegant)?

Help is much appreciated, and I apologise in advance if I'm asking a dumb question for my first one!

(Note: had to edit the URLs because I'm new here!)

3 Likes
2

I was recently messing with etcd3's gRPC interface and encountered a somewhat-related problem in that there wasn't really a straightforward way to run protoc against their definition files since they had various dependencies that had to be in particular places, and there was no documentation (that I could find) on doing it properly.

I ended up hacking up the script that they use to generate Go from their proto files and simply checking the results into my repo. IMO, this is the way to go, since it doesn't require any downstream builders to have protoc installed, the proto files shouldn't really be changing, and the output of protoc shouldn't depend at all on the target build machine.

My etcd fork: https://github.com/jechase/rust-etcd