Bundled Sphinx extensions (experimental)#
scikitplot._externals._sphinx_ext is Scikit-Plots’ private namespace for
bundled documentation extensions and the small support libraries shared by
those extensions. The namespace is intentionally lazy: importing
scikitplot._externals._sphinx_ext does not eagerly import Sphinx or every
optional dependency.
These modules are useful to projects that build the Scikit-Plots documentation stack, but the leading underscore is significant. Treat them as experimental integration APIs rather than as the stable plotting API of Scikit-Plots. Pin Scikit-Plots when a documentation deployment depends on their exact configuration or generated markup.
pydata-component-list
sphinx-jinja
How to enable an extension#
Use the installed Scikit-Plots namespace in conf.py:
extensions = [
"scikitplot._externals._sphinx_ext._sphinx_gallery_grid",
]
A source checkout can also expose the same tree as _sphinx_ext for
standalone documentation development. Use one namespace authority per
Sphinx application. Do not mix _sphinx_ext.* and
scikitplot._externals._sphinx_ext.* registrations in the same build.
Choose the owner by task#
Task |
Use |
Registration |
|---|---|---|
Remove terminal control sequences from LaTeX output |
Direct Sphinx extension |
|
List installed PyData Sphinx Theme components |
Direct Sphinx extension |
|
Markdown export, AI links, assistant panel and related integrations |
Direct Sphinx extension |
|
JSON-first Learn content materialization |
Direct Sphinx extension |
|
Page feedback UI and feedback service contract |
Direct Sphinx extension |
|
Structured YAML card galleries |
Direct Sphinx extension |
|
JupyterLite notebook preparation for Sphinx-Gallery |
Extension plus Sphinx-Gallery callables |
|
Render |
Direct Sphinx extension |
|
Machine-consumable Markdown and |
Experimental, maintenance-gated extension |
|
Generic filtering, grouping and browser controls |
Support library; do not register directly |
|
YouTube reference parsing and player-option validation |
Support library; do not register directly |
|
Catalog-driven YouTube galleries |
Direct Sphinx extension |
|
Individual YouTube, Vimeo and PeerTube players |
Direct Sphinx extension |
Extension relationships#
The collection/video stack deliberately has one owner for each concern:
_sphinx_youtube_core provider grammar and leaf-player options
|
_sphinxcontrib_youtube individual video players
|
_sphinx_youtube_gallery YouTube catalog/query adapter
|
_sphinx_gallery_grid generic cards/layout
|
_sphinx_collection filtering/grouping/browser controls and assets
_sphinx_youtube_gallery loads its required sibling extensions itself.
Projects may still register those dependencies explicitly, but should not
replace one layer with a second implementation of the same behavior.
Security and reproducibility#
Several extensions process documentation-authored YAML, URLs, generated files, or remote-service configuration. Follow these repository contracts:
keep credentials and write-capable tokens out of
conf.pyand generated HTML;keep file-backed gallery data inside the documentation source tree;
prefer deterministic build-time inputs and explicit opt-in network behavior;
treat generated RST/Markdown as derived output when the owning extension identifies another source as canonical;
do not infer that a missing aggregate, cache entry, or optional dependency is equivalent to a successful zero/empty result.
The child guides call out additional boundaries where they are part of the implemented contract.