/tf_pb_without_tf

Generate tensorflow (and tf serving) protobuf interface without tensorflow dependency

Primary LanguageShellMIT LicenseMIT

Generate python interfaces for the protobufs used by Tensorflow and TF Serving, for a client which does not use TF

Why? Well, say you're writing a client that connects to a Tensorflow model server and asks it to classify an image or whatever. The client will need to send over the image using the protobuf format that the server expects, but there's no reason for the client to have to have all of tensorflow installed. Just the protobuf interface. After all tensorflow is a big package and takes up a lot of disk space and memory and so forth.

So...? You see, Tensorflow's official client implementations depend on the tensorflow package as of this writing. For instance, if you want to run their example MNIST client, you'd need to have tensorflow installed even just to construct the prediction request predict_pb2.PredictRequest, and to call their tf.contrib.util.make_tensor_proto function. So you can't easily use their work to make a client API that is totally free of tensorflow.

Then... Yup. You just execute ./generate_pbs.sh. The script has to download the TF and TF Serving repositories, but it produces a python package that you can then use without having to have TF installed. Execute it from this directory, and make sure that the sample__init__.py and setup.py files are there.

And then I just... You just from tf_pb import TensorProto, yes.

Is there anything to customize? Maybe a little bit. I wrote it for use in a client which will make a prediction request using the default signature. So in sample__init__.py, it imports things like TensorProto and PredictRequest so that they'll be at the package's top level. If you need different defaults, you might want to import them at the top level there too. Just follow the examples I've laid out. If you're not sure where exactly they are, you can always dig around in the TF or TF Serving repositories' source code. Things like ClassifyRequest probably won't be too far from PredictRequest, etc.