Request: add `yaml()` method

[martindurant]

Can there be a way to convert a .plot(arguments) call into YAML text output, appropriate for inclusion in an Intake catalog? I assume this is easy to achieve, and would remove the friction for catalog authors wishing to define a set of quick-plots.

[philippjfr]

Definitely think this is a good idea. The API I can imagine would be something like:

df.plot(..., yaml=True)

This would be very easy to achieve, but may be a bit weird since it changes the return type. Something more standard like:

df.plot(...).to_yaml()

would be a lot harder to achieve.

[martindurant]

I think the weird API would be fine, I only see this being used as part of a trial/error phase where the data provider is deciding on the best parameters to put into the catalog.

[jsignell]

It seems that it might be useful to support this in general in holoviews. There are hints at it in the docs: http://holoviews.org/user_guide/Customizing_Plots.html#Yaml-equivalent

[jbednar]

The general HoloViews version would be dependent on holoviz/param#153 , which is not much work to finish up, but does take some concentration. It's been abandoned, but it really needs someone to return to it and resurrect it cleanly, because serializing to YAML or JSON comes up quite often.

[philippjfr]

Those are all slightly different things though. Serializing HoloViews in general means serializing the data along with any parameters and plot and style options, which is quite a difficult problem with a wide range of solutions and the resulting representation will be quite verbose even if you separate the data itself from this representation.

Since the hvplot API is a lot more concise the serialized yaml will be a lot more readable and when you combine it with intake you also solve the data serialization problem.

Another way to think of it is serializing the input specification for a plot, which can be done independently of the data. The other major benefit of that approach is that you can declare operations to be performed on the data, e.g. datashading, contouring etc., while serializing holoviews objects would either produce static output or require something like cloudpickle to store dynamic/lazy objects like DynamicMaps.

[jbednar]

The section that Julia was pointing to (http://holoviews.org/user_guide/Customizing_Plots.html#Yaml-equivalent) was about serializing options, not plots with data, which doesn't have issues with data serialization. But yes, serializing the invocation of hvplot is nearly sufficient to reconstitute the plot, given that the data is held separately, unlike serializing HoloViews options.

[philippjfr]

True, I suppose I got confused because I'm not sure how serializing options relates to param serialization as you suggested. While plot options do reflect underlying parameters on the plot classes, style and normalization options do not and none of them are stored on parameters and therefore would not benefit from a param serialization mechanism. So I thought you were talking about a full serialization protocol.

[jbednar]

Ah, good point. So I was confused as well!

[jsignell]

I have definitely not thought about this as much as you guys, but I was definitely not trying to suggest that any data be stored, just field names, ranges, options...

[martindurant]

Yes, to be sure, thinking nothing more than

>>> df.plot(attribute1="thing")
[plot appears]

->

>>> df.plot(attribute1="thing", yaml=True)
plots:
  catterplot:
    attribute1: thing    
[plot appears]

(or need to capture the output of the plot call to get this string repr)

[martindurant]

(all welcome to look up what a catterplot is like!)