minimal-example

Minimal Examples

A reproducer a tester pastes and runs unchanged to check a fix, so keep it short enough to skim, not study. These are the traps specific to HoloViz reproducers.

References

• Reproducing Browser Bugs: a Playwright script an agent runs to confirm a bug that only shows up in the browser, with a screenshot per step and a programmatic check for whether the bug is still there.

Contents

• Reproducer Traps

Reproducer Traps

• Render explicitly with pn.serve(obj); don't end on the bare object. In a script the notebook _repr_html_ never fires, so obj alone does nothing and any render-time error (layout sizing, projection, aspect, colorbar) stays hidden. pn.serve renders any HoloViews/hvPlot/Panel object and surfaces it.
• Declare the backend the behavior depends on (hv.extension('bokeh') vs 'matplotlib'). The same code renders through different code paths per backend, so an implicit backend makes the report ambiguous.
• Import every submodule the snippet uses explicitly depending on the module, e.g. from holoviews.operation.datashader import datashade rather than reaching for hv.operation.datashader. Submodule attribute access only resolves once something has already imported it, so a snippet written in a warm session runs for you and raises AttributeError for the first person to paste it cold.
• Check the finished snippet in a fresh interpreter, not the session you wrote it in and not against your patched checkout. A session carries imports, registered extensions and monkeypatches that the reader's won't, and a local dev install reports its own version, so the __version__ you print should be the one you are reporting against.
• Generate data inline and seed it (rng = np.random.default_rng(0)), or load a dataset the reader can fetch too, e.g. a URL, xr.tutorial.open_dataset, or bokeh.sampledata. Just don't read_csv a local path only you have.
• For a bug, paste the versions that matter (hv.__version__, pn.__version__, and the backend: bokeh/matplotlib/cartopy). HoloViz bugs are usually version-specific.
• Say where the before/after shows up. pn.serve blocks and renders in a browser, so a visual symptom is only visible there, while an exception or a warning lands in the terminal. A tester watching the wrong one concludes nothing happened.
• End with a one-line comment on the before behavior (what a tester sees without the fix) and the after (what a correct run should show), so they know what to look for without studying the code.