Add Agnostic Plotting Protocol#843
Conversation
- Define FigureProtocol with Capability flags for backend-neutral plotting - Add plot_line, plot_markers, plot_area, plot_ohlc, plot_histogram, plot_bars, plot_hline, and plot_zone methods to FigureMixin - Implement backend registry (register_backend, get_backend, list_backends) with Plotly registered as the default built-in backend - Add create_figure() factory that routes through the registry and respects settings['plotting']['default_backend'] - Add resolve_backend/resolve_backend_for_fig helpers for downstream migration of existing plot methods - Add assert_plotly_only_kwargs/assert_plotly_only_method guards for graceful non-Plotly backend error reporting - Expose new API surface on vbt.plotting.* and top-level vbt.* - Add default_backend='plotly' to plotting settings - Add comprehensive test suites for protocol conformance and backend registry
- Add hover_text sequence length validation in plot_markers to raise ValueError on mismatched lengths - Add plot_zone tests: minimal, color/opacity, None-param omission, subplot domain resolution - Add subplot column routing tests (1x2 and 2x2 layouts) to catch regressions that ignore the col dimension - Add use_widgets_setting fixture to parametrize subplot tests over both Figure and FigureWidget - Add create_figure tests for rows-only, cols-only, and figure= kwarg routing through make_subplots - Add backend registry tests for kwarg forwarding and unregistered default backend error handling - Add to_html protocol conformance test - Add None-param omission tests for plot_histogram and plot_area - Fix test_unknown_backend_raises_keyerror to assert correct key name - Compare add_hline compat test against go.Figure reference instead of hardcoded Plotly internals
|
Hi @ChadThackray, thanks for this PR. I'm currently working on adding a Rust backend, so we have two major features in progress at the same time, which is great. One thing we should align on is the naming convention. There are two things that could conceptually be called a "backend": Numba, Rust, and other compute backends, and Plotly, Lightweight Charts, and other plotting backends. I've already started building the compute backend and have been using the variable name I can rename everything on my side to |
|
@polakowo yes we should ensure the concepts are distinct to avoid confusion later. I'm happy to use |
|
@ChadThackray Numba & Rust engine and Plotly & Lightweight Charts renderer. Sounds great. |
- Rename `default_backend` setting to `default_renderer` and update all references - Rename `register_backend`, `get_backend`, `list_backends` to `register_renderer`, `get_renderer`, `list_renderers` - Rename `resolve_backend`, `resolve_backend_for_fig` helpers and `backend_name` class attribute to `renderer_name` - Rename `_BACKEND_REGISTRY` to `_RENDERER_REGISTRY` and `BackendFactory` to `RendererFactory` - Rename `tests/test_plotting_backend.py` to `tests/test_plotting_renderer.py` - Clarify in `create_figure` docstring that vectorbt's `renderer=` selects the plotting library, distinct from Plotly's own `fig.show(renderer=...)` output-format kwarg
|
@polakowo Great! Should be done now ready for your review |
|
Hi @ChadThackray, thanks, I’ve merged the PR. I’ve also published the next major vectorbt release with Rust support, so I won’t be working on the master branch anytime soon. Since this release both overhauls and reformats many files, please make sure to pull the latest version of master to avoid dealing with conflicts later. Cheers! |
|
@ChadThackray heads up, I've reverted the merge for now. After thinking about it more, since the plotting protocol is a multi-PR feature set I'd rather not ship partial pieces on master between releases. For instance, if I decide to ship some unrelated feature I'd have to ship your protocol as well, which isn't the cleanest approach. Could you create a long-lived branch (such as Nothing wrong with the code itself, this is purely about release logistics. |
|
@polakowo That makes sense. I've created a branch here: https://github.com/ChadThackray/vectorbt/tree/feature/plotting-renderers If you would like to host the branch on the main repo here I believe you will need to create a branch first as I don't have permissions. Then I can target incremental merges there |
|
@ChadThackray you are right, branch protections are on. I've created the branch here: https://github.com/polakowo/vectorbt/tree/plotting-renderers. It's all yours! |
2 participants
As progress towards #815, this PR introduces a new
Protocol,FigureProtocol, which lays out the contract that any plotting backend should fulfill.In this PR I have focused on creating the protocol itself as well as adding
PlotlyFigureProtocolMixin, which implements theFigureProtocolfor plotly specifically. This is purely additive, no user facing changes.We also setup the machinery for plugging in new backends later with a registry.
Next steps would be migrating internal callers to use the protocol as opposed to direct plotly calls where possible, which will help refine the design of the protocol before adding lightweight charts support
As always let me know any suggestions or if a different direction would be preferred.