Add SavedModelBundle API

[Enet4]

This is more of a request for feedback rather than something ready to merge now. As this concern was exposed in #68, I built an API that gathers the loaded session and meta-graph information into a bundle. When combined with the latest protobuf crate and protoc-generated sources, it is then possible to retrieve signature definitions from the meta-graph with something like this:

// load the bundle using the given properties
let mut graph = Graph::new();
let bundle = Session::from_saved_model_to_bundle(
    &SessionOptions::new(), &["train", "serve"], &mut graph, "path/to/model")?;
// read metagraph
let metagraph: MetaGraphDef = parse_from_bytes(&bundle.meta_graph_def)?;
// fetch signature definition
let signatures = metagraph.get_signature_def();

Since this crate is still independent from protobuf, this extra constructor method currently provides a vector of raw bytes.

Feedback would be certainly welcome. In particular, is the method's name ok? Should SavedModelBundle be just a tuple? Or maybe a tuple struct? This API might also depend on whether this crate will have its own protobuf serialization/deserialization code in the future. It seems that we cannot obtain certain features already available in the Python API without this.

[adamcrume]

I originally left out proto support because TensorFlow uses proto3 and no Rust libraries at the time supported proto3. We'll have to decide at some point whether to leave serialization/deserialization to the user, or to pick from https://github.com/stepancheg/rust-protobuf or something else. If we choose a proto library, we should be able to write the API in a way that hides the choice of library from the user, but it's still a commitment. @jhseu, do you have any thoughts on TensorFlow proto concerns? I see that the Go and Java bindings expose the config proto as a raw byte array to the user.

I'd prefer any public APIs to use full-fledged structs rather than tuples or tuple structs. They have slightly more boilerplate, but they're also more extensible and explicit. Within the implementation, I think tuples and tuple structs are fine.

As for the method name, to keep more consistent with the Go API and the Java API, I think it would make sense to move it to SavedModelBundle and name it load.

[Enet4]

As for the method name, to keep more consistent with the Go API and the Java API, I think it would make sense to move it to SavedModelBundle and name it load.

That is now done in 43f6bf9.

[jhseu]

Yeah, leaving serialization/deserialization up to the user seems like the most reasonable option given the fragmented protobuf situation in Rust.

If there were a hard dependency, prost seems like the most reasonable protobuf crate right now, but it's too new to depend on.

[Enet4]

If there were a hard dependency, prost seems like the most reasonable protobuf crate right now, but it's too new to depend on.

I can't speak for prost, but rust-protobuf worked pretty well for what I'm doing. Regardless, yes, we can keep the meta-graph as a byte vector for now.

[adamcrume]

Can you add a test?

[adamcrume]

For new code, ? is preferred over try!.

[adamcrume]

Typo: "definition"

[Enet4]

Can you add a test?

Is it ok for me to add a "test-resources" folder with a known saved model for this?

[adamcrume]

Sure, go ahead.

[Enet4]

The requested changes were made. 🙂

[adamcrume]

Thanks!