serving: Unable to compile Protobuf for Golang

OS Platform: MacOS 10.14.5 On TF-Serving r1.14

I’ve checked other closed issues regarding this topic but still not able to find a clear solution.

I tried: protoc -I ./ -I ../tensorflow/ \ betterchen@Yangs-MacBook-Pro --go_out=plugins=grpc:$GOPATH/src/github.com/lejiskin/tf_server_be/protos \ tensorflow_serving/apis/prediction_service.proto

The generated pb makes import cycle error and is not useful at all.

Please clarify this issue.

It’s better to create an official document of “How to build a Golang gRPC client for TF-Serving”

Thanks

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 16 (3 by maintainers)

Most upvoted comments

I wrote a script to generate TF Serving gRPC interfaces for Go, but it would be nice if we could run protoc directly without jumping through these hoops.

@1dustycy,

You can find community build Golang packages for TF Serving Client here and here as mentioned in above comment.

Please let us know if this issue can be closed. Thank you!

@grantstephens

Hi, I stored required protobuf files and scripts to get proto files for TF-Serving 2.7 APIs in this repository. And I wrote a sample client code with golang for TensorFlow Serving 2.7 in this link. I hope these repositories can help you.

If anyone else runs into this issue, I found what seems to be a simple workaround (specifically on r1.15 branch)

The issue is that tensorflow_serving/apis/prediction_log.proto needs a LogMetadata from tensorflow_serving/core/logging.proto, which itself needs a ModelSpec from tensorflow_serving/apis/model.proto. The dependency from tensorflow_serving/apis -> tensorflow_serving/core -> tensorflow_serving/apis makes Go fail.

I did a grep -r "logging.proto" to verify that it only gets imported by apis/prediction_log.proto. This meant I could just move logging.proto from the core/ directory into the apis/ directory and change the import in prediction_log.proto to import it from the new location (i.e. import "tensorflow_serving/apis/logging.proto";)

Not sure what effects this might have on any of the actual TFS code, but it seems to be fine if all you want to do is have access to the TFS protos from within GoLang