Add support to maintain backend information in an element

[ea42gh]

for example,
element.opts(plot=dict(height=100), backend='bokeh')

[ea42gh]

It would also be useful to be able to query which backend(s) is attached to a particular hv object.
Use case: a dictionary of hv objects rendered as
* a bokeh holomap, with hover and zoom turned on
* a matplotlib svg output
e.g., see https://github.com/ea42gh/HoloviewsPlayground/blob/master/GenerateDocument.ipynb

[jlstevens]

Generally we try to keep our objects separate from the backends - the only thing that can be backend specific are the custom option trees that are associated with the objects. As a result, I'm not sure whether this proposal makes sense but maybe @philippjfr sees a concrete way to implement this suggestion in a way that integrates well with everything else.

[jbednar]

Can't this be an option, conceptually like any other? The option trees are already backend specific; there could just be an optional label that declares that this particular backend should be used by default for this object if not otherwise declared with %%output, etc.

[philippjfr]

Generally we try to keep our objects separate from the backends

I think this makes sense on the opts method (and possible the magic too), currently the .opts magic implicitly sets the supplied options on the OptionsTree for the currently selected backend. Letting the user supply an explicit backend to assign the options to makes perfect sense to me and would get around various annoyances setting options for multiple backends.

[jlstevens]

It might not be too hard to implement although I rather not add anything new to the options system.

My worry is that supporting this makes both specification and parsing harder than it already is now: there are already more enough issues to worry about without making it more complicated than it already is.

[philippjfr]

My worry is that supporting this makes both specification and parsing harder than it already is now

I don't quite see the issue, it's both easy to implement (literally just needs to pass backend to the Store.options calls inside .opts), gets around a major annoyance, and by default nothing changes. I think the global backend state is a bit weird and optionally being explicit about what backend you're actually specifying options for is a good thing.

[jlstevens]

I can make a PR attempting this to see how it goes and so we can discuss this further.

[ea42gh]

I'd like to be able to set options for both 'matplotlib' AND 'bokeh' for the same object.
Which set is used would simply depend on the backend set in the current cell.

[jbednar]

Oh, have we been confused about what you are requesting then? Your latest comment sounds like a duplicate of #803.

[philippjfr]

Oh, have we been confused about what you are requesting then?

I don't think so, I was the one to originally suggest the proposal outlined here, #803 is specifically about the magics while this is about .opts. I'm also no longer even so sure about the proposal for the magics outlined there.

[ea42gh]

Just looked at #803 - sounds confusing.
What I was driving at is that I would like to do something akin to
the function error_evolution_plots()
in https://github.com/ea42gh/HoloviewsPlayground/blob/master/GenerateDocument.ipynb

but setting the both plot options
h=h.opts(bokeh_spike_plot_opts,'bokeh').opts( mpl_spike_plot_opts, 'matplotlib' )
and have the chosen options used for the object depend on the active backend:

%%output backend='bokeh'
h     # renders using the bokeh opts

%%output backend='matplotlib'
h     # renders using the matplotlib opts

What got me thinking about it was that I wanted bokeh in the notebook
to be able to zoom, pan, hover...
but needed matplotlib to save the figure to file

[philippjfr]

This has been addressed, both .opts and .options now let you specify an explicit backend.