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)
I wrote a script to generate TF Serving gRPC interfaces for Go, but it would be nice if we could run
protocdirectly 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.15branch)The issue is that
tensorflow_serving/apis/prediction_log.protoneeds aLogMetadatafromtensorflow_serving/core/logging.proto, which itself needs aModelSpecfromtensorflow_serving/apis/model.proto. The dependency fromtensorflow_serving/apis->tensorflow_serving/core->tensorflow_serving/apismakes Go fail.I did a
grep -r "logging.proto"to verify that it only gets imported byapis/prediction_log.proto. This meant I could just movelogging.protofrom thecore/directory into theapis/directory and change the import inprediction_log.prototo 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