Convience methods to write to/from json

[jthorton]

While writing tests for the industry benchmark I find myself writing the same two bits of code a lot to write and load AlchemicalNetworks to json file. I think it would make sense to add them as functions to avoid repeated code. I would suggest a to_json_file method and a from_json_file class method. In the future we might consider other supported file types like messagepack so a general to_file and from_file might be more appropriate with the file type inferred from the name.

I noticed that the Transformation object can already be written to json using its dump method so I think having some general serialisation options on the GufeTokenizable class would be very useful!

[dotsdl]

Agree with this @jthorton! Although this gets a bit tricky, since there are multiple representations a GufeTokenizable can take, including dict, shallow_dict, keyed_dict, and now keyed_chain. All of these are readily JSON-serializable except shallow_dict, but which one should be used for e.g. to_json?

What may help is to create a gufe.serialization submodule with convenience functions, such as to_json, from_json, to_msgpack, from_msgpack, etc. These functions could by default return an in-memory representation, but could optionally take a filename or file-like object to write to.

Do you think that would be sufficient, or still be annoying as a downstream user of GufeTokenizables?

[jthorton]

All of these are readily JSON-serializable except shallow_dict, but which one should be used for e.g. to_json?

I would say the most minimal one which can be used to roundtrip the same object currently I just use dict as I wasn't sure but if the to/from methods could handle this for me that would be fantastic!

What may help is to create a gufe.serialization submodule with convenience functions, such as to_json, from_json, to_msgpack, from_msgpack, etc. These functions could by default return an in-memory representation, but could optionally take a filename or file-like object to write to.

Great idea, I think that would help a lot and save downstream implementations.