Registry / devops / sphinx-multiversion

sphinx-multiversion

JSON →
library0.2.4pypypiunverified

sphinx-multiversion is a Sphinx extension that enables the creation of multiple versions of your project's documentation. It supports building documentation from different branches or tags in a Git repository, allowing users to easily switch between versions. The current version is 0.2.4. Releases are infrequent but stable, often coinciding with new Sphinx releases or major feature additions.

pip install sphinx-multiversion
INSTALL
IMPORT
SIG · SPHINX-MULTIVERSIO
S
sphinx-multiversion
devopspythonv0.2.4
Install
5.2s avg
Import
Disk
94MB
Pass rate
10/ 10
Env Coverage10 / 10
glibc
3.93.13
musl
3.93.13
Install & Compatibility
Where this runs
tested against v0.2.4 · pip install
no network on importno background threads
Install × environment matrix
Each cell = how many times install + import succeeded across repeated harness runs. Partial = flaky.
glibc = Debian/Ubuntu slim · musl = Alpine Linux
musl
py 3.103.910 runs
installs and imports cleanly · install 0.0s · import 0.000s · 92.2MB
glibc
py 3.103.910 runs
installs and imports cleanly · install 5.2s · import 0.000s · 93MB
94MB installed
● package 94MB
Code
Verified usage

Verified import paths — ran on the pinned version, not inferred.

sphinx_multiversion
extensions = ['sphinx_multiversion', 'sphinx.ext.autodoc'] # in conf.py
import sphinx_multiversion
`sphinx-multiversion` is a Sphinx extension. It is enabled by adding its name (`'sphinx_multiversion'`) to the `extensions` list in your `conf.py` file. It is not designed for direct Python import into application code.

To set up `sphinx-multiversion`, first add it to your `extensions` list in `conf.py`. Then, configure `smv_tag_whitelist` and `smv_branch_whitelist` with regular expressions to specify which Git tags and branches should have their documentation built. Finally, run the `sphinx-multiversion` command with your source and output directories.

# conf.py import os project = 'My Multi-version Project' copyright = '2024, Your Name' version = '0.1' release = '0.1.0' extensions = [ 'sphinx_multiversion', 'sphinx.ext.autodoc', ] # Multiversion configuration (adjust regex as needed) # Builds documentation for tags matching vX.Y.Z smv_tag_whitelist = r'^v\d+\.\d+\.\d+$' # Builds documentation for 'main' and 'develop' branches smv_branch_whitelist = r'^(main|develop)$' # Default remote to fetch from smv_remote_whitelist = 'origin' # To build: # Run this command from your documentation root (where conf.py is located): # sphinx-multiversion . _build/html
Debug
Known issues
gotcha`conf.py` compatibility across versions. `sphinx-multiversion` runs a separate build for each version. Ensure your `conf.py` is compatible across all versions you want to build. Changes in newer branches won't automatically apply to old tags.
fix
Design `conf.py` to be forward/backward compatible, or use conditional logic (e.g., `if 'v1.0.0' in os.environ.get('SMV_TAG', ''):`) to adapt settings for specific versions. Consider maintaining separate `conf.py` files for significantly different versions if necessary.
affects: All versions
gotchaPerformance issues with many versions or large repositories. Building documentation for a large number of branches/tags in a sizable repository can be resource-intensive and time-consuming, especially in CI/CD pipelines.
fix
Use `smv_branch_whitelist` and `smv_tag_whitelist` aggressively to limit the number of versions built. Implement caching for Git operations in CI/CD, or consider dedicated build environments.
affects: All versions
gotchaOutput directory structure and version linking. Incorrect configuration of `smv_outputdir_format` or base URLs can lead to broken links or incorrect version switching in the generated HTML, especially when deployed to a web server.
fix
Carefully configure `smv_outputdir_format` to match your deployment strategy. Ensure your web server is set up to correctly serve static files from the generated version directories, or rely on `sphinx-multiversion`'s own version switcher (usually works out-of-the-box).
affects: 0.2.0 onwards
gotchaBroken relative paths in documentation files when versions are nested. Hardcoding relative paths (e.g., `../_static/image.png`) in `.rst` or `.md` files might break when a document is built under a different version subdirectory (e.g., `/v1.0.0/my_doc.html` vs `/main/my_doc.html`).
fix
Use Sphinx's standard `:doc:`, `:ref:`, and `|version|` variables where possible. For assets, use absolute paths from the root of the documentation project (e.g., `/_static/image.png`) if your web server configuration allows, or use Sphinx's `image` directive which handles paths correctly.
affects: All versions
gotchaCompatibility issues with major Sphinx upgrades. `sphinx-multiversion` relies on Sphinx internals. Upgrading Sphinx to a major new version (e.g., 6.x to 7.x) without verifying `sphinx-multiversion` compatibility can lead to unexpected build failures.
fix
Always test `sphinx-multiversion` with new major Sphinx versions in a test environment before deploying to production. Check `sphinx-multiversion` release notes for compatibility announcements.
affects: All versions
Upgrade
Version history
0.2.4latest on PyPI · released Oct 3, 2024
Audit
Dependencies
SphinxrequiredCore dependency as `sphinx-multiversion` is a Sphinx extension.
Agent activity
11 hits · last 30 days
node
8
OpenAI (training)
1
Resources
sphinx-multiversion — pip install sphinx-multiversion · libregistry