mirror of
https://github.com/sphinx-doc/sphinx.git
synced 2026-10-25 06:38:09 -05:00
Merge branch 'master' into docs/extension-tutorials
This commit is contained in:
914 files changed
+164720
-43568
No files matched your search
+21
-13
@@ -5,21 +5,15 @@ environment:
|
||||
PYTHONWARNINGS: all
|
||||
|
||||
matrix:
|
||||
- PYTHON: 27
|
||||
DOCUTILS: 0.12
|
||||
TEST_IGNORE: --ignore py35
|
||||
- PYTHON: 27
|
||||
DOCUTILS: 0.13.1
|
||||
TEST_IGNORE: --ignore py35
|
||||
- PYTHON: 36
|
||||
DOCUTILS: 0.13.1
|
||||
- PYTHON: 36-x64
|
||||
DOCUTILS: 0.13.1
|
||||
- PYTHON: 37
|
||||
- PYTHON: 37-x64
|
||||
|
||||
install:
|
||||
- C:\Python%PYTHON%\python.exe -m pip install -U pip setuptools
|
||||
- C:\Python%PYTHON%\python.exe -m pip install docutils==%DOCUTILS%
|
||||
- C:\Python%PYTHON%\python.exe -m pip install -r test-reqs.txt
|
||||
- C:\Python%PYTHON%\python.exe -m pip install .[test,websupport]
|
||||
|
||||
cache:
|
||||
- '%LOCALAPPDATA%\pip\Cache'
|
||||
|
||||
# No automatic build, just run python tests
|
||||
build: off
|
||||
@@ -39,10 +33,24 @@ test_script:
|
||||
if (-not $test_ignore) { $test_ignore = '' }
|
||||
$tests = $env:TEST
|
||||
if (-not $tests) { $tests = '' }
|
||||
& "C:\Python$($env:PYTHON)\python.exe" run.py $test_ignore.Split(' ') --junitxml .junit.xml $tests.Split(' ')
|
||||
& "C:\Python$($env:PYTHON)\python.exe" -m pytest $test_ignore.Split(' ') --junitxml .junit.xml $tests.Split(' ')
|
||||
Pop-Location
|
||||
if ($LastExitCode -eq 1) { Write-Host "Test Failures Occurred, leaving for test result parsing" }
|
||||
elseif ($LastExitCode -ne 0) { Write-Host "Other Error Occurred, aborting"; exit $LastExitCode }
|
||||
|
||||
after_test:
|
||||
- ps: (New-Object System.Net.WebClient).UploadFile("https://ci.appveyor.com/api/testresults/junit/$($env:APPVEYOR_JOB_ID)", (Resolve-Path (Join-Path tests .junit.xml)))
|
||||
|
||||
after_build:
|
||||
# Remove old or huge cache files to hopefully not exceed the 1GB cache limit.
|
||||
#
|
||||
# If the cache limit is reached, the cache will not be updated (of not even
|
||||
# created in the first run). So this is a trade of between keeping the cache
|
||||
# current and having a cache at all.
|
||||
# NB: This is done only `on_success` since the cache in uploaded only on
|
||||
# success anyway.
|
||||
- C:\cygwin\bin\find "%LOCALAPPDATA%\pip" -type f -mtime +360 -delete
|
||||
- C:\cygwin\bin\find "%LOCALAPPDATA%\pip" -type f -size +10M -delete
|
||||
- C:\cygwin\bin\find "%LOCALAPPDATA%\pip" -empty -delete
|
||||
# Show size of cache
|
||||
- C:\cygwin\bin\du -hs "%LOCALAPPDATA%\pip\Cache"
|
||||
@@ -6,4 +6,6 @@ jobs:
|
||||
working_directory: /sphinx
|
||||
steps:
|
||||
- checkout
|
||||
- run: make test PYTHON=/python3.4/bin/python
|
||||
- run: /python3.5/bin/pip install -U pip setuptools
|
||||
- run: /python3.5/bin/pip install -U .[test,websupport]
|
||||
- run: make test PYTHON=/python3.5/bin/python
|
||||
@@ -0,0 +1,8 @@
|
||||
coverage:
|
||||
status:
|
||||
project:
|
||||
default:
|
||||
enabled: no
|
||||
patch:
|
||||
default:
|
||||
enabled: no
|
||||
@@ -1,5 +1,13 @@
|
||||
Subject: <what happen when you do on which document project>
|
||||
|
||||
<!--
|
||||
Important: This is a list of issues for Sphinx, not a forum.
|
||||
If you'd like to post a question, please move to sphinx-users group.
|
||||
https://groups.google.com/forum/#!forum/sphinx-users
|
||||
|
||||
Thanks,
|
||||
-->
|
||||
|
||||
### Problem
|
||||
- <Detail of problem>
|
||||
|
||||
|
||||
+10
-1
@@ -5,11 +5,17 @@
|
||||
|
||||
.dir-locals.el
|
||||
.cache/
|
||||
.idea
|
||||
.mypy_cache/
|
||||
.pytest_cache/
|
||||
.ropeproject/
|
||||
TAGS
|
||||
.tags
|
||||
.tox
|
||||
.tox/
|
||||
.tx/
|
||||
.venv/
|
||||
.coverage
|
||||
htmlcov
|
||||
.DS_Store
|
||||
sphinx/pycode/Grammar*pickle
|
||||
distribute-*
|
||||
@@ -19,6 +25,9 @@ build/
|
||||
dist/
|
||||
Sphinx.egg-info/
|
||||
doc/_build/
|
||||
doc/locale/
|
||||
tests/.coverage
|
||||
tests/build/
|
||||
utils/regression_test.js
|
||||
|
||||
node_modules/
|
||||
+43
-38
@@ -1,48 +1,53 @@
|
||||
language: python
|
||||
sudo: false
|
||||
dist: trusty
|
||||
cache:
|
||||
directories:
|
||||
- $HOME/.cache/pip
|
||||
python:
|
||||
- "pypy-5.4.1"
|
||||
- "3.6"
|
||||
- "3.5"
|
||||
- "3.4"
|
||||
- "2.7"
|
||||
- "nightly"
|
||||
cache: pip
|
||||
|
||||
env:
|
||||
global:
|
||||
- TEST='-v --durations 25'
|
||||
- PYTHONFAULTHANDLER=x
|
||||
- PYTHONWARNINGS=all
|
||||
- SKIP_LATEX_BUILD=1
|
||||
matrix:
|
||||
- DOCUTILS=0.12
|
||||
- DOCUTILS=0.13.1
|
||||
- IS_PYTHON=true
|
||||
|
||||
matrix:
|
||||
exclude:
|
||||
- python: "3.4"
|
||||
env: DOCUTILS=0.12
|
||||
- python: "3.5"
|
||||
env: DOCUTILS=0.12
|
||||
- python: "3.6"
|
||||
env: DOCUTILS=0.12
|
||||
- python: nightly
|
||||
env: DOCUTILS=0.12
|
||||
- python: "pypy-5.4.1"
|
||||
env: DOCUTILS=0.12
|
||||
addons:
|
||||
apt:
|
||||
packages:
|
||||
- graphviz
|
||||
- imagemagick
|
||||
include:
|
||||
- python: '3.5'
|
||||
env:
|
||||
- TOXENV=du13
|
||||
- python: '3.6'
|
||||
env:
|
||||
- TOXENV=py36
|
||||
- PYTEST_ADDOPTS="--cov ./ --cov-append --cov-config setup.cfg"
|
||||
- python: '3.7'
|
||||
env: TOXENV=py37
|
||||
dist: xenial
|
||||
sudo: true
|
||||
- python: 'nightly'
|
||||
env: TOXENV=py38
|
||||
dist: xenial
|
||||
sudo: true
|
||||
- python: '3.6'
|
||||
env: TOXENV=docs
|
||||
- python: '3.6'
|
||||
env: TOXENV=mypy
|
||||
- python: '3.6'
|
||||
env: TOXENV=flake8
|
||||
|
||||
- language: node_js
|
||||
node_js:
|
||||
- 10.7
|
||||
env: IS_PYTHON=false
|
||||
before_script:
|
||||
- export DISPLAY=:99.0
|
||||
- sh -e /etc/init.d/xvfb start
|
||||
|
||||
install:
|
||||
- pip install -U pip setuptools
|
||||
- pip install docutils==$DOCUTILS
|
||||
- pip install -r test-reqs.txt
|
||||
- if [[ $TRAVIS_PYTHON_VERSION == '3.6' ]]; then python3.6 -m pip install mypy typed-ast; fi
|
||||
- if [ $IS_PYTHON = true ]; then pip install -U tox codecov; fi
|
||||
- if [ $IS_PYTHON = false ]; then npm install; fi
|
||||
|
||||
script:
|
||||
- flake8
|
||||
- if [[ $TRAVIS_PYTHON_VERSION == '3.6' ]]; then make style-check type-check test-async; fi
|
||||
- if [[ $TRAVIS_PYTHON_VERSION != '3.6' ]]; then make test; fi
|
||||
- if [ $IS_PYTHON = true ]; then tox -- -v; fi
|
||||
- if [ $IS_PYTHON = false ]; then npm test; fi
|
||||
|
||||
after_success:
|
||||
- if [[ -e .coverage ]]; then codecov -e $TOXENV; fi
|
||||
@@ -14,10 +14,12 @@ Other co-maintainers:
|
||||
* Takeshi Komiya <@tk0miya>
|
||||
* Jean-François Burnol <@jfbu>
|
||||
* Yoshiki Shibukawa <@shibu_jp>
|
||||
* Timotheus Kampik - <@TimKam>
|
||||
|
||||
Other contributors, listed alphabetically, are:
|
||||
|
||||
* Alastair Houghton -- Apple Help builder
|
||||
* Alexander Todorov -- inheritance_diagram tests and improvements
|
||||
* Andi Albrecht -- agogo theme
|
||||
* Jakob Lykke Andersen -- Rewritten C++ domain
|
||||
* Henrique Bastos -- SVG support for graphviz extension
|
||||
@@ -29,15 +31,20 @@ Other contributors, listed alphabetically, are:
|
||||
* Kevin Dunn -- MathJax extension
|
||||
* Josip Dzolonga -- coverage builder
|
||||
* Buck Evan -- dummy builder
|
||||
* Matthew Fernandez -- todo extension fix
|
||||
* Hernan Grecco -- search improvements
|
||||
* Horst Gutmann -- internationalization support
|
||||
* Martin Hans -- autodoc improvements
|
||||
* Zac Hatfield-Dodds -- doctest reporting improvements
|
||||
* Doug Hellmann -- graphviz improvements
|
||||
* Timotheus Kampik - JS theme & search enhancements
|
||||
* Tim Hoffmann -- theme improvements
|
||||
* Antti Kaihola -- doctest extension (skipif option)
|
||||
* Dave Kuhlman -- original LaTeX writer
|
||||
* Blaise Laflamme -- pyramid theme
|
||||
* Chris Lamb -- reproducibility fixes
|
||||
* Thomas Lamb -- linkcheck builder
|
||||
* Łukasz Langa -- partial support for autodoc
|
||||
* Martin Larralde -- additional napoleon admonitions
|
||||
* Ian Lee -- quickstart improvements
|
||||
* Robert Lehmann -- gettext builder (GSOC project)
|
||||
* Dan MacKinlay -- metadata fixes
|
||||
@@ -45,10 +52,12 @@ Other contributors, listed alphabetically, are:
|
||||
* Will Maier -- directory HTML builder
|
||||
* Jacob Mason -- websupport library (GSOC project)
|
||||
* Glenn Matthews -- python domain signature improvements
|
||||
* Kurt McKee -- documentation updates
|
||||
* Roland Meister -- epub builder
|
||||
* Ezio Melotti -- collapsible sidebar JavaScript
|
||||
* Bruce Mitchener -- Minor epub improvement
|
||||
* Daniel Neuhäuser -- JavaScript domain, Python 3 support (GSOC)
|
||||
* Julien Palard -- Colspan and rowspan in text builder
|
||||
* Christopher Perkins -- autosummary integration
|
||||
* Benjamin Peterson -- unittests
|
||||
* \T. Powers -- HTML output improvements
|
||||
@@ -57,18 +66,21 @@ Other contributors, listed alphabetically, are:
|
||||
* Stefan Seefeld -- toctree improvements
|
||||
* Gregory Szorc -- performance improvements
|
||||
* Taku Shimizu -- epub3 builder
|
||||
* Antonio Valentino -- qthelp builder
|
||||
* Antonio Valentino -- qthelp builder, docstring inheritance
|
||||
* Filip Vavera -- napoleon todo directive
|
||||
* Pauli Virtanen -- autodoc improvements, autosummary extension
|
||||
* Eric N. Vander Weele -- autodoc improvements
|
||||
* Stefan van der Walt -- autosummary extension
|
||||
* Thomas Waldmann -- apidoc module fixes
|
||||
* John Waltman -- Texinfo builder
|
||||
* Barry Warsaw -- setup command improvements
|
||||
* Sebastian Wiesner -- image handling, distutils support
|
||||
* Michael Wilson -- Intersphinx HTTP basic auth support
|
||||
* Matthew Woodcraft -- text output improvements
|
||||
* Joel Wurtz -- cellspanning support in LaTeX
|
||||
* Hong Xu -- svg support in imgmath extension and various bug fixes
|
||||
* Stephen Finucane -- setup command improvements and documentation
|
||||
* Daniel Pizetta -- inheritance diagram improvements
|
||||
|
||||
Many thanks for all contributions!
|
||||
|
||||
|
||||
+91
-42
@@ -33,10 +33,10 @@ Bug Reports and Feature Requests
|
||||
|
||||
If you have encountered a problem with Sphinx or have an idea for a new
|
||||
feature, please submit it to the `issue tracker`_ on GitHub or discuss it
|
||||
on the sphinx-dev mailing list.
|
||||
on the `sphinx-dev`_ mailing list.
|
||||
|
||||
For bug reports, please include the output produced during the build process
|
||||
and also the log file Sphinx creates after it encounters an un-handled
|
||||
and also the log file Sphinx creates after it encounters an unhandled
|
||||
exception. The location of this file should be shown towards the end of the
|
||||
error message.
|
||||
|
||||
@@ -45,6 +45,7 @@ issue. If possible, try to create a minimal project that produces the error
|
||||
and post that instead.
|
||||
|
||||
.. _`issue tracker`: https://github.com/sphinx-doc/sphinx/issues
|
||||
.. _`sphinx-dev`: mailto:sphinx-dev@googlegroups.com
|
||||
|
||||
|
||||
Contributing to Sphinx
|
||||
@@ -58,10 +59,10 @@ of the core developers before it is merged into the main repository.
|
||||
#. Check for open issues or open a fresh issue to start a discussion around a
|
||||
feature idea or a bug.
|
||||
#. If you feel uncomfortable or uncertain about an issue or your changes, feel
|
||||
free to email sphinx-dev@googlegroups.com.
|
||||
free to email the *sphinx-dev* mailing list.
|
||||
#. Fork `the repository`_ on GitHub to start making your changes to the
|
||||
**master** branch for next major version, or **stable** branch for next
|
||||
minor version.
|
||||
``master`` branch for next major version, or ``X.Y`` branch for next
|
||||
minor version (see `Branch Model`_).
|
||||
#. Write a test which shows that the bug was fixed or that the feature works
|
||||
as expected.
|
||||
#. Send a pull request and bug the maintainer until it gets merged and
|
||||
@@ -91,17 +92,22 @@ These are the basic steps needed to start developing on Sphinx.
|
||||
#. Checkout the appropriate branch.
|
||||
|
||||
For changes that should be included in the next minor release (namely bug
|
||||
fixes), use the ``stable`` branch. ::
|
||||
fixes), use the ``X.Y`` branch. ::
|
||||
|
||||
git checkout stable
|
||||
git checkout X.Y
|
||||
|
||||
For new features or other substantial changes that should wait until the
|
||||
next major release, use the ``master`` branch.
|
||||
next major release, use the ``master`` branch (see `Branch Model`_ for
|
||||
detail).
|
||||
|
||||
#. Optional: setup a virtual environment. ::
|
||||
#. Setup a virtual environment.
|
||||
|
||||
virtualenv ~/sphinxenv
|
||||
. ~/sphinxenv/bin/activate
|
||||
This is not necessary for unit testing, thanks to ``tox``, but it is
|
||||
necessary if you wish to run ``sphinx-build`` locally or run unit tests
|
||||
without the help of ``tox``. ::
|
||||
|
||||
virtualenv ~/.venv
|
||||
. ~/.venv/bin/activate
|
||||
pip install -e .
|
||||
|
||||
#. Create a new working branch. Choose any name you like. ::
|
||||
@@ -112,40 +118,59 @@ These are the basic steps needed to start developing on Sphinx.
|
||||
|
||||
For tips on working with the code, see the `Coding Guide`_.
|
||||
|
||||
#. Test, test, test. Possible steps:
|
||||
#. Test, test, test.
|
||||
|
||||
* Run the unit tests::
|
||||
Testing is best done through ``tox``, which provides a number of targets and
|
||||
allows testing against multiple different Python environments:
|
||||
|
||||
pip install -r test-reqs.txt
|
||||
make test
|
||||
* To list all possible targets::
|
||||
|
||||
* Again, it's useful to turn on deprecation warnings on so they're shown in
|
||||
the test output::
|
||||
tox -av
|
||||
|
||||
PYTHONWARNINGS=all make test
|
||||
* To run unit tests for a specific Python version, such as 3.6::
|
||||
|
||||
* Build the documentation and check the output for different builders::
|
||||
tox -e py36
|
||||
|
||||
cd doc
|
||||
make clean html latexpdf
|
||||
* To run unit tests for a specific Python version and turn on deprecation
|
||||
warnings on so they're shown in the test output::
|
||||
|
||||
* Run code style checks and type checks (type checks require mypy)::
|
||||
PYTHONWARNINGS=all tox -e py36
|
||||
|
||||
make style-check
|
||||
make type-check
|
||||
* To run code style and type checks::
|
||||
|
||||
* Run the unit tests under different Python environments using
|
||||
:program:`tox`::
|
||||
tox -e mypy
|
||||
tox -e flake8
|
||||
|
||||
pip install tox
|
||||
tox -v
|
||||
* Arguments to ``pytest`` can be passed via ``tox``, e.g. in order to run a
|
||||
particular test::
|
||||
|
||||
* Add a new unit test in the ``tests`` directory if you can.
|
||||
tox -e py36 tests/test_module.py::test_new_feature
|
||||
|
||||
* To build the documentation::
|
||||
|
||||
tox -e docs
|
||||
|
||||
* To build the documentation in multiple formats::
|
||||
|
||||
tox -e docs -- -b html,latexpdf
|
||||
|
||||
* To run JavaScript tests with `Karma <https://karma-runner.github.io>`_,
|
||||
execute the following commands (requires `Node.js <https://nodejs.org>`_)::
|
||||
|
||||
npm install
|
||||
npm run test
|
||||
|
||||
You can also test by installing dependencies in your local environment. ::
|
||||
|
||||
pip install .[test]
|
||||
|
||||
New unit tests should be included in the ``tests`` directory where
|
||||
necessary:
|
||||
|
||||
* For bug fixes, first add a test that fails without your changes and passes
|
||||
after they are applied.
|
||||
|
||||
* Tests that need a sphinx-build run should be integrated in one of the
|
||||
* Tests that need a ``sphinx-build`` run should be integrated in one of the
|
||||
existing test modules if possible. New tests that to ``@with_app`` and
|
||||
then ``build_all`` for a few assertions are not good since *the test suite
|
||||
should not take more than a minute to run*.
|
||||
@@ -169,7 +194,7 @@ These are the basic steps needed to start developing on Sphinx.
|
||||
git push origin feature-xyz
|
||||
|
||||
#. Submit a pull request from your branch to the respective branch (``master``
|
||||
or ``stable``) on ``sphinx-doc/sphinx`` using the GitHub interface.
|
||||
or ``X.Y``).
|
||||
|
||||
#. Wait for a core developer to review your changes.
|
||||
|
||||
@@ -262,7 +287,7 @@ Debugging Tips
|
||||
code by running the command ``make clean`` or using the
|
||||
:option:`sphinx-build -E` option.
|
||||
|
||||
* Use the :option:`sphinx-build -P` option to run Pdb on exceptions.
|
||||
* Use the :option:`sphinx-build -P` option to run ``pdb`` on exceptions.
|
||||
|
||||
* Use ``node.pformat()`` and ``node.asdom().toxml()`` to generate a printable
|
||||
representation of the document structure.
|
||||
@@ -283,8 +308,26 @@ Debugging Tips
|
||||
in `this repository <https://github.com/shibukawa/snowball-stemmer.jsx>`_.
|
||||
You can get the resulting JavaScript files using the following command::
|
||||
|
||||
$ npm install
|
||||
$ node_modules/.bin/grunt build # -> dest/*.global.js
|
||||
npm install
|
||||
node_modules/.bin/grunt build # -> dest/*.global.js
|
||||
|
||||
|
||||
Branch Model
|
||||
------------
|
||||
|
||||
Sphinx project uses following branches for developing.
|
||||
|
||||
``master``
|
||||
Used for main development. All improvement and refactoring, bug fixes
|
||||
are allowed.
|
||||
|
||||
``X.Y``
|
||||
Where ``X.Y`` is the ``MAJOR.MINOR`` release. Used to maintain current
|
||||
stable release. Only bug fixes and stable changes are allowed. Only the
|
||||
most recent stable release is currently retained. When a new version is
|
||||
released, the old release branch will be deleted and replaced by an
|
||||
equivalent tag.
|
||||
|
||||
|
||||
Deprecating a feature
|
||||
---------------------
|
||||
@@ -299,14 +342,17 @@ There are a couple reasons that code in Sphinx might be deprecated:
|
||||
no longer needs to support the older version of Python that doesn't include
|
||||
the library, the library will be deprecated in Sphinx.
|
||||
|
||||
As the :ref:`deprecation-policy` describes,
|
||||
the first release of Sphinx that deprecates a feature (``A.B``) should raise a
|
||||
``RemovedInSphinxXXWarning`` (where XX is the Sphinx version where the feature
|
||||
will be removed) when the deprecated feature is invoked. Assuming we have good
|
||||
test coverage, these warnings are converted to errors when running the test
|
||||
suite with warnings enabled: ``python -Wall tests/run.py``. Thus, when adding
|
||||
a ``RemovedInSphinxXXWarning`` you need to eliminate or silence any warnings
|
||||
generated when running the tests.
|
||||
As the :ref:`deprecation-policy` describes, the first release of Sphinx that
|
||||
deprecates a feature (``A.B``) should raise a ``RemovedInSphinxXXWarning``
|
||||
(where ``XX`` is the Sphinx version where the feature will be removed) when the
|
||||
deprecated feature is invoked. Assuming we have good test coverage, these
|
||||
warnings are converted to errors when running the test suite with warnings
|
||||
enabled::
|
||||
|
||||
pytest -Wall
|
||||
|
||||
Thus, when adding a ``RemovedInSphinxXXWarning`` you need to eliminate or
|
||||
silence any warnings generated when running the tests.
|
||||
|
||||
.. _deprecation-policy:
|
||||
|
||||
@@ -362,3 +408,6 @@ and other ``test_*.py`` files under ``tests`` directory.
|
||||
|
||||
.. versionadded:: 1.6
|
||||
``sphinx.testing`` as a experimental.
|
||||
|
||||
.. versionadded:: 1.8
|
||||
Sphinx also runs JavaScript tests.
|
||||
@@ -12,235 +12,398 @@ interesting examples.
|
||||
Documentation using the alabaster theme
|
||||
---------------------------------------
|
||||
|
||||
* CodePy: https://documen.tician.de/codepy/
|
||||
* MeshPy: https://documen.tician.de/meshpy/
|
||||
* PyCuda: https://documen.tician.de/pycuda/
|
||||
* PyLangAcq: http://pylangacq.org/
|
||||
* `Alabaster <https://alabaster.readthedocs.io/>`__
|
||||
* `Blinker <https://pythonhosted.org/blinker/>`__
|
||||
* `Calibre <https://manual.calibre-ebook.com/>`__
|
||||
* `Click <http://click.pocoo.org/>`__ (customized)
|
||||
* `coala <https://docs.coala.io/>`__ (customized)
|
||||
* `CodePy <https://documen.tician.de/codepy/>`__
|
||||
* `Fabric <https://docs.fabfile.org/>`__
|
||||
* `Fityk <https://fityk.nieto.pl/>`__
|
||||
* `Flask <http://flask.pocoo.org/docs/>`__
|
||||
* `Flask-OpenID <https://pythonhosted.org/Flask-OpenID/>`__
|
||||
* `Invoke <https://docs.pyinvoke.org/>`__
|
||||
* `Jinja <http://jinja.pocoo.org/docs/>`__
|
||||
* `Lino <http://www.lino-framework.org/>`__ (customized)
|
||||
* `marbl <https://getmarbl.readthedocs.io/>`__
|
||||
* `MDAnalysis <https://www.mdanalysis.org/docs/>`__ (customized)
|
||||
* `MeshPy <https://documen.tician.de/meshpy/>`__
|
||||
* `Molecule <https://molecule.readthedocs.io/>`__
|
||||
* `PyCUDA <https://documen.tician.de/pycuda/>`__
|
||||
* `PyOpenCL <https://documen.tician.de/pyopencl/>`__
|
||||
* `PyLangAcq <http://pylangacq.org/>`__
|
||||
* `pytest <https://docs.pytest.org/>`__ (customized)
|
||||
* `python-apt <https://apt.alioth.debian.org/python-apt-doc/>`__
|
||||
* `PyVisfile <https://documen.tician.de/pyvisfile/>`__
|
||||
* `Requests <http://www.python-requests.org/>`__
|
||||
* `searx <https://asciimoo.github.io/searx/>`__
|
||||
* `Spyder <https://docs.spyder-ide.org/>`__ (customized)
|
||||
* `Tablib <http://docs.python-tablib.org/>`__
|
||||
* `urllib3 <https://urllib3.readthedocs.io/>`__ (customized)
|
||||
* `Werkzeug <http://werkzeug.pocoo.org/docs/>`__ (customized)
|
||||
|
||||
Documentation using the classic theme
|
||||
-------------------------------------
|
||||
|
||||
* APSW: https://rogerbinns.github.io/apsw/
|
||||
* Calibre: http://manual.calibre-ebook.com/
|
||||
* Cython: http://docs.cython.org/
|
||||
* Cormoran: http://cormoran.nhopkg.org/docs/
|
||||
* Director: http://pythonhosted.org/director/
|
||||
* F2py: http://f2py.sourceforge.net/docs/
|
||||
* Genomedata:
|
||||
http://noble.gs.washington.edu/proj/genomedata/doc/1.2.2/genomedata.html
|
||||
* GSL Shell: http://www.nongnu.org/gsl-shell/
|
||||
* Hands-on Python Tutorial:
|
||||
http://anh.cs.luc.edu/python/hands-on/3.1/handsonHtml/
|
||||
* Hedge: https://documen.tician.de/hedge/
|
||||
* Leo: http://leoeditor.com/
|
||||
* Lino: http://www.lino-framework.org/
|
||||
* mpmath: http://mpmath.org/doc/current/
|
||||
* OpenEXR: http://excamera.com/articles/26/doc/index.html
|
||||
* OpenGDA: http://www.opengda.org/gdadoc/html/
|
||||
* openWNS: http://docs.openwns.org/
|
||||
* Pioneers and Prominent Men of Utah: http://pioneers.rstebbing.com/
|
||||
* PyCantonese: http://pycantonese.org/
|
||||
* Pyevolve: http://pyevolve.sourceforge.net/
|
||||
* PyMQI: http://pythonhosted.org/pymqi/
|
||||
* pySPACE: http://pyspace.github.io/pyspace/
|
||||
* Python: https://docs.python.org/3/
|
||||
* python-apt: http://apt.alioth.debian.org/python-apt-doc/
|
||||
* PyUblas: https://documen.tician.de/pyublas/
|
||||
* Ring programming language: http://ring-lang.sourceforge.net/doc/index.html
|
||||
* Scapy: http://www.secdev.org/projects/scapy/doc/
|
||||
* Segway: http://noble.gs.washington.edu/proj/segway/doc/1.1.0/segway.html
|
||||
* SymPy: http://docs.sympy.org/
|
||||
* WTForms: http://wtforms.simplecodes.com/docs/
|
||||
* z3c: http://www.ibiblio.org/paulcarduner/z3ctutorial/
|
||||
|
||||
|
||||
Documentation using a customized version of the classic theme
|
||||
-------------------------------------------------------------
|
||||
|
||||
* Advanced Generic Widgets:
|
||||
http://xoomer.virgilio.it/infinity77/AGW_Docs/index.html
|
||||
* Arb: http://fredrikj.net/arb/
|
||||
* Bazaar: http://doc.bazaar.canonical.com/en/
|
||||
* CakePHP: http://book.cakephp.org/2.0/en/index.html
|
||||
* Chaco: http://docs.enthought.com/chaco/
|
||||
* Chef: https://docs.chef.io/index.html
|
||||
* Djagios: http://djagios.org/
|
||||
* EZ-Draw: http://pageperso.lif.univ-mrs.fr/~edouard.thiel/ez-draw/doc/en/html/ez-manual.html
|
||||
* GetFEM++: http://home.gna.org/getfem/
|
||||
* Google or-tools:
|
||||
https://or-tools.googlecode.com/svn/trunk/documentation/user_manual/index.html
|
||||
* GPAW: https://wiki.fysik.dtu.dk/gpaw/
|
||||
* Grok: http://grok.zope.org/doc/current/
|
||||
* Kaa: http://api.freevo.org/kaa-base/
|
||||
* LEPL: http://www.acooke.org/lepl/
|
||||
* Mayavi: http://docs.enthought.com/mayavi/mayavi/
|
||||
* NICOS: http://trac.frm2.tum.de/nicos/doc/nicos-master/index.html
|
||||
* NOC: http://redmine.nocproject.org/projects/noc
|
||||
* NumPy: http://docs.scipy.org/doc/numpy/reference/
|
||||
* OpenCV: http://docs.opencv.org/
|
||||
* Peach^3: http://peach3.nl/doc/latest/userdoc/
|
||||
* Pygame: http://www.pygame.org/docs/
|
||||
* Sage: http://www.sagemath.org/doc/
|
||||
* SciPy: http://docs.scipy.org/doc/scipy/reference/
|
||||
* simuPOP: http://simupop.sourceforge.net/manual_release/build/userGuide.html
|
||||
* Sprox: http://sprox.org/
|
||||
* TurboGears: http://turbogears.readthedocs.org/en/latest/
|
||||
* Varnish: https://www.varnish-cache.org/docs/
|
||||
* Zentyal: http://doc.zentyal.org/
|
||||
* Zope: http://docs.zope.org/zope2/index.html
|
||||
* zc.async: http://pythonhosted.org/zc.async/1.5.0/
|
||||
|
||||
* `Advanced Generic Widgets <http://xoomer.virgilio.it/infinity77/AGW_Docs/>`__ (customized)
|
||||
* `Apache CouchDB <http://docs.couchdb.org/>`__ (customized)
|
||||
* `APSW <https://rogerbinns.github.io/apsw/>`__
|
||||
* `Arb <http://arblib.org/>`__
|
||||
* `Bazaar <http://doc.bazaar.canonical.com/>`__ (customized)
|
||||
* `Beautiful Soup <https://www.crummy.com/software/BeautifulSoup/bs4/doc/>`__
|
||||
* `Blender <https://docs.blender.org/api/current/>`__
|
||||
* `Bugzilla <https://bugzilla.readthedocs.io/>`__
|
||||
* `Buildbot <https://docs.buildbot.net/latest/>`__
|
||||
* `CMake <https://cmake.org/documentation/>`__ (customized)
|
||||
* `Chaco <https://docs.enthought.com/chaco/>`__ (customized)
|
||||
* `CORE <https://downloads.pf.itd.nrl.navy.mil/docs/core/core-html/>`__
|
||||
* `CORE Python modules <https://downloads.pf.itd.nrl.navy.mil/docs/core/core-python-html/>`__
|
||||
* `Cormoran <http://cormoran.nhopkg.org/docs/>`__
|
||||
* `DEAP <https://deap.readthedocs.io/>`__ (customized)
|
||||
* `Director <https://pythonhosted.org/director/>`__
|
||||
* `EZ-Draw <https://pageperso.lif.univ-mrs.fr/~edouard.thiel/ez-draw/doc/en/html/ez-manual.html>`__ (customized)
|
||||
* `F2py <http://f2py.sourceforge.net/docs/>`__
|
||||
* `Generic Mapping Tools (GMT) <https://gmt.soest.hawaii.edu/doc/latest/>`__ (customized)
|
||||
* `Genomedata <https://noble.gs.washington.edu/proj/genomedata/doc/1.3.3/>`__
|
||||
* `GetFEM++ <http://getfem.org/>`__ (customized)
|
||||
* `Glasgow Haskell Compiler <https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/>`__ (customized)
|
||||
* `Grok <http://grok.zope.org/doc/current/>`__ (customized)
|
||||
* `GROMACS <http://manual.gromacs.org/documentation/>`__
|
||||
* `GSL Shell <https://www.nongnu.org/gsl-shell/>`__
|
||||
* `Hands-on Python Tutorial <https://anh.cs.luc.edu/python/hands-on/3.1/handsonHtml/>`__
|
||||
* `Kaa <https://api.freevo.org/kaa-base/>`__ (customized)
|
||||
* `Leo <https://leoeditor.com/>`__
|
||||
* `LEPL <http://www.acooke.org/lepl/>`__ (customized)
|
||||
* `Mayavi <https://docs.enthought.com/mayavi/mayavi/>`__ (customized)
|
||||
* `MediaGoblin <https://mediagoblin.readthedocs.io/>`__ (customized)
|
||||
* `mpmath <http://mpmath.org/doc/current/>`__
|
||||
* `OpenCV <https://docs.opencv.org/>`__ (customized)
|
||||
* `OpenEXR <http://excamera.com/articles/26/doc/index.html>`__
|
||||
* `OpenGDA <http://www.opengda.org/gdadoc/html/>`__
|
||||
* `Peach^3 <https://peach3.nl/doc/latest/userdoc/>`__ (customized)
|
||||
* `Plone <https://docs.plone.org/>`__ (customized)
|
||||
* `PyEMD <https://pyemd.readthedocs.io/>`__
|
||||
* `Pyevolve <http://pyevolve.sourceforge.net/>`__
|
||||
* `Pygame <https://www.pygame.org/docs/>`__ (customized)
|
||||
* `PyMQI <https://pythonhosted.org/pymqi/>`__
|
||||
* `PyQt4 <http://pyqt.sourceforge.net/Docs/PyQt4/>`__ (customized)
|
||||
* `PyQt5 <http://pyqt.sourceforge.net/Docs/PyQt5/>`__ (customized)
|
||||
* `Python 2 <https://docs.python.org/2/>`__
|
||||
* `Python 3 <https://docs.python.org/3/>`__ (customized)
|
||||
* `Python Packaging Authority <https://www.pypa.io/>`__ (customized)
|
||||
* `Ring programming language <http://ring-lang.sourceforge.net/doc/>`__ (customized)
|
||||
* `SageMath <https://doc.sagemath.org/>`__ (customized)
|
||||
* `Segway <https://noble.gs.washington.edu/proj/segway/doc/1.1.0/segway.html>`__
|
||||
* `simuPOP <http://simupop.sourceforge.net/manual_release/build/userGuide.html>`__ (customized)
|
||||
* `Sprox <http://sprox.org/>`__ (customized)
|
||||
* `SymPy <https://docs.sympy.org/>`__
|
||||
* `TurboGears <https://turbogears.readthedocs.io/>`__ (customized)
|
||||
* `tvtk <https://docs.enthought.com/mayavi/tvtk/>`__
|
||||
* `Varnish <https://www.varnish-cache.org/docs/>`__ (customized, alabaster for index)
|
||||
* `Waf <https://waf.io/apidocs/>`__
|
||||
* `wxPython Phoenix <https://wxpython.org/Phoenix/docs/html/main.html>`__ (customized)
|
||||
* `Yum <http://yum.baseurl.org/api/yum/>`__
|
||||
* `z3c <https://www.ibiblio.org/paulcarduner/z3ctutorial/>`__
|
||||
* `zc.async <https://pythonhosted.org/zc.async/>`__ (customized)
|
||||
* `Zope <https://docs.zope.org/zope2/>`__ (customized)
|
||||
|
||||
Documentation using the sphinxdoc theme
|
||||
---------------------------------------
|
||||
|
||||
* Fityk: http://fityk.nieto.pl/
|
||||
* MapServer: http://mapserver.org/
|
||||
* Matplotlib: http://matplotlib.org/
|
||||
* Music21: http://web.mit.edu/music21/doc/index.html
|
||||
* NetworkX: http://networkx.github.io/
|
||||
* Pweave: http://mpastell.com/pweave/
|
||||
* Pyre: http://docs.danse.us/pyre/sphinx/
|
||||
* Pysparse: http://pysparse.sourceforge.net/
|
||||
* PyTango:
|
||||
http://www.esrf.eu/computing/cs/tango/tango_doc/kernel_doc/pytango/latest/index.html
|
||||
* Python Wild Magic: http://vmlaker.github.io/pythonwildmagic/
|
||||
* Reteisi: http://www.reteisi.org/contents.html
|
||||
* Sqlkit: http://sqlkit.argolinux.org/
|
||||
* Turbulenz: http://docs.turbulenz.com/
|
||||
* WebFaction: https://docs.webfaction.com/
|
||||
* `cartopy <https://scitools.org.uk/cartopy/docs/latest/>`__
|
||||
* `Jython <http://www.jython.org/docs/>`__
|
||||
* `Matplotlib <https://matplotlib.org/>`__
|
||||
* `MDAnalysis Tutorial <https://www.mdanalysis.org/MDAnalysisTutorial/>`__
|
||||
* `NetworkX <https://networkx.github.io/>`__
|
||||
* `PyCantonese <http://pycantonese.org/>`__
|
||||
* `Pyre <http://docs.danse.us/pyre/sphinx/>`__
|
||||
* `pySPACE <https://pyspace.github.io/pyspace/>`__
|
||||
* `Pysparse <http://pysparse.sourceforge.net/>`__
|
||||
* `PyTango <https://www.esrf.eu/computing/cs/tango/tango_doc/kernel_doc/pytango/latest/>`__
|
||||
* `Python Wild Magic <https://vmlaker.github.io/pythonwildmagic/>`__ (customized)
|
||||
* `Reteisi <http://www.reteisi.org/contents.html>`__ (customized)
|
||||
* `Sqlkit <http://sqlkit.argolinux.org/>`__ (customized)
|
||||
* `Turbulenz <http://docs.turbulenz.com/>`__
|
||||
|
||||
Documentation using the nature theme
|
||||
------------------------------------
|
||||
|
||||
* `Alembic <http://alembic.zzzcomputing.com/>`__
|
||||
* `Cython <http://docs.cython.org/>`__
|
||||
* `easybuild <https://easybuild.readthedocs.io/>`__
|
||||
* `jsFiddle <http://doc.jsfiddle.net/>`__
|
||||
* `libLAS <https://www.liblas.org/>`__ (customized)
|
||||
* `Lmod <https://lmod.readthedocs.io/>`__
|
||||
* `MapServer <https://mapserver.org/>`__ (customized)
|
||||
* `Pandas <https://pandas.pydata.org/pandas-docs/stable/>`__
|
||||
* `pyglet <https://pyglet.readthedocs.io/>`__ (customized)
|
||||
* `Setuptools <https://setuptools.readthedocs.io/>`__
|
||||
* `Spring Python <https://docs.spring.io/spring-python/1.2.x/sphinx/html/>`__
|
||||
* `StatsModels <https://www.statsmodels.org/>`__ (customized)
|
||||
* `Sylli <http://sylli.sourceforge.net/>`__
|
||||
|
||||
Documentation using another builtin theme
|
||||
-----------------------------------------
|
||||
|
||||
* ASE: https://wiki.fysik.dtu.dk/ase/ (sphinx_rtd_theme)
|
||||
* C/C++ Development with Eclipse: http://eclipsebook.in/ (agogo)
|
||||
* ESWP3 (http://eswp3.org) (sphinx_rtd_theme)
|
||||
* Jinja: http://jinja.pocoo.org/ (scrolls)
|
||||
* jsFiddle: http://doc.jsfiddle.net/ (nature)
|
||||
* libLAS: http://www.liblas.org/ (nature)
|
||||
* Linguistica: http://linguistica-uchicago.github.io/lxa5/ (sphinx_rtd_theme)
|
||||
* MoinMoin: https://moin-20.readthedocs.io/en/latest/ (sphinx_rtd_theme)
|
||||
* MPipe: http://vmlaker.github.io/mpipe/ (sphinx13)
|
||||
* Paver: http://paver.readthedocs.io/en/latest/
|
||||
* pip: https://pip.pypa.io/en/latest/ (sphinx_rtd_theme)
|
||||
* Programmieren mit PyGTK und Glade (German):
|
||||
http://www.florian-diesch.de/doc/python-und-glade/online/ (agogo)
|
||||
* PyPubSub: http://pypubsub.readthedocs.io/ (bizstyle)
|
||||
* Pyramid web framework:
|
||||
http://docs.pylonsproject.org/projects/pyramid/en/latest/ (pyramid)
|
||||
* Quex: http://quex.sourceforge.net/doc/html/main.html
|
||||
* Satchmo: http://docs.satchmoproject.com/en/latest/ (sphinx_rtd_theme)
|
||||
* Setuptools: http://pythonhosted.org/setuptools/ (nature)
|
||||
* SimPy: http://simpy.readthedocs.org/en/latest/
|
||||
* Spring Python: http://docs.spring.io/spring-python/1.2.x/sphinx/html/ (nature)
|
||||
* sqlparse: http://python-sqlparse.googlecode.com/svn/docs/api/index.html
|
||||
(agogo)
|
||||
* Sylli: http://sylli.sourceforge.net/ (nature)
|
||||
* Tuleap Open ALM: https://tuleap.net/doc/en/ (nature)
|
||||
* Valence: http://docs.valence.desire2learn.com/ (haiku)
|
||||
* `Breathe <https://breathe.readthedocs.io/>`__ (haiku)
|
||||
* `MPipe <https://vmlaker.github.io/mpipe/>`__ (sphinx13)
|
||||
* `NLTK <https://www.nltk.org/>`__ (agogo)
|
||||
* `Programmieren mit PyGTK und Glade (German) <https://www.florian-diesch.de/doc/python-und-glade/online/>`__ (agogo, customized)
|
||||
* `PyPubSub <https://pypubsub.readthedocs.io/>`__ (bizstyle)
|
||||
* `Pylons <https://docs.pylonsproject.org/projects/pylons-webframework/>`__ (pyramid)
|
||||
* `Pyramid web framework <https://docs.pylonsproject.org/projects/pyramid/>`__ (pyramid)
|
||||
* `Sphinx <http://www.sphinx-doc.org/>`__ (sphinx13) :-)
|
||||
* `Valence <https://docs.valence.desire2learn.com/>`__ (haiku, customized)
|
||||
|
||||
Documentation using sphinx_rtd_theme
|
||||
------------------------------------
|
||||
|
||||
Documentation using a custom theme/integrated in a site
|
||||
-------------------------------------------------------
|
||||
* `Annotator <http://docs.annotatorjs.org/>`__
|
||||
* `Ansible <https://docs.ansible.com/>`__ (customized)
|
||||
* `Arcade <http://arcade.academy/>`__
|
||||
* `aria2 <https://aria2.github.io/manual/en/html/>`__
|
||||
* `ASE <https://wiki.fysik.dtu.dk/ase/>`__
|
||||
* `Autofac <http://docs.autofac.org/>`__
|
||||
* `BigchainDB <https://docs.bigchaindb.com/>`__
|
||||
* `Blocks <https://blocks.readthedocs.io/>`__
|
||||
* `bootstrap-datepicker <https://bootstrap-datepicker.readthedocs.io/>`__
|
||||
* `Certbot <https://letsencrypt.readthedocs.io/>`__
|
||||
* `Chainer <https://docs.chainer.org/>`__ (customized)
|
||||
* `CherryPy <https://docs.cherrypy.org/>`__
|
||||
* `cloud-init <https://cloudinit.readthedocs.io/>`__
|
||||
* `CodeIgniter <https://www.codeigniter.com/user_guide/>`__
|
||||
* `Conda <https://conda.io/docs/>`__
|
||||
* `Corda <https://docs.corda.net/>`__
|
||||
* `Dask <https://dask.pydata.org/>`__
|
||||
* `Databricks <https://docs.databricks.com/>`__ (customized)
|
||||
* `Dataiku DSS <https://doc.dataiku.com/>`__
|
||||
* `DNF <https://dnf.readthedocs.io/>`__
|
||||
* `edX <https://docs.edx.org/>`__
|
||||
* `Electrum <http://docs.electrum.org/>`__
|
||||
* `Elemental <http://libelemental.org/documentation/dev/>`__
|
||||
* `ESWP3 <https://eswp3.readthedocs.io/>`__
|
||||
* `Ethereum Homestead <http://www.ethdocs.org/>`__
|
||||
* `Fidimag <https://fidimag.readthedocs.io/>`__
|
||||
* `Flake8 <http://flake8.pycqa.org/>`__
|
||||
* `FluidDyn <https://fluiddyn.readthedocs.io/>`__
|
||||
* `Fluidsim <https://fluidsim.readthedocs.io/>`__
|
||||
* `GeoNode <http://docs.geonode.org/>`__
|
||||
* `Godot <https://godot.readthedocs.io/>`__
|
||||
* `Graylog <http://docs.graylog.org/>`__
|
||||
* `GPAW <https://wiki.fysik.dtu.dk/gpaw/>`__ (customized)
|
||||
* `HDF5 for Python (h5py) <http://docs.h5py.org/>`__
|
||||
* `Hyperledger Fabric <https://hyperledger-fabric.readthedocs.io/>`__
|
||||
* `Hyperledger Sawtooth <https://intelledger.github.io/>`__
|
||||
* `IdentityServer <http://docs.identityserver.io/>`__
|
||||
* `Idris <http://docs.idris-lang.org/>`__
|
||||
* `javasphinx <https://bronto-javasphinx.readthedocs.io/>`__
|
||||
* `Julia <https://julia.readthedocs.io/>`__
|
||||
* `Jupyter Notebook <https://jupyter-notebook.readthedocs.io/>`__
|
||||
* `Lasagne <https://lasagne.readthedocs.io/>`__
|
||||
* `latexindent.pl <https://latexindentpl.readthedocs.io/>`__
|
||||
* `Linguistica <https://linguistica-uchicago.github.io/lxa5/>`__
|
||||
* `Linux kernel <https://www.kernel.org/doc/html/latest/index.html>`__
|
||||
* `MathJax <https://docs.mathjax.org/>`__
|
||||
* `MDTraj <http://mdtraj.org/latest/>`__ (customized)
|
||||
* `MICrobial Community Analysis (micca) <http://micca.org/docs/latest/>`__
|
||||
* `MicroPython <https://docs.micropython.org/>`__
|
||||
* `Minds <https://www.minds.org/docs/>`__ (customized)
|
||||
* `Mink <http://mink.behat.org/>`__
|
||||
* `Mockery <http://docs.mockery.io/>`__
|
||||
* `mod_wsgi <https://modwsgi.readthedocs.io/>`__
|
||||
* `MoinMoin <https://moin-20.readthedocs.io/>`__
|
||||
* `Mopidy <https://docs.mopidy.com/>`__
|
||||
* `MyHDL <http://docs.myhdl.org/>`__
|
||||
* `Nextflow <https://www.nextflow.io/docs/latest/index.html>`__
|
||||
* `NICOS <https://forge.frm2.tum.de/nicos/doc/nicos-master/>`__ (customized)
|
||||
* `Pelican <http://docs.getpelican.com/>`__
|
||||
* `picamera <https://picamera.readthedocs.io/>`__
|
||||
* `Pillow <https://pillow.readthedocs.io/>`__
|
||||
* `pip <https://pip.pypa.io/>`__
|
||||
* `Paver <https://paver.readthedocs.io/>`__
|
||||
* `peewee <http://docs.peewee-orm.com/>`__
|
||||
* `Phinx <http://docs.phinx.org/>`__
|
||||
* `phpMyAdmin <https://docs.phpmyadmin.net/>`__
|
||||
* `PROS <https://pros.cs.purdue.edu/v5/>`__ (customized)
|
||||
* `Pweave <http://mpastell.com/pweave/>`__
|
||||
* `PyPy <http://doc.pypy.org/>`__
|
||||
* `python-sqlparse <https://sqlparse.readthedocs.io/>`__
|
||||
* `PyVISA <https://pyvisa.readthedocs.io/>`__
|
||||
* `Read The Docs <https://docs.readthedocs.io/>`__
|
||||
* `Free your information from their silos (French) <http://redaction-technique.org/>`__ (customized)
|
||||
* `Releases Sphinx extension <https://releases.readthedocs.io/>`__
|
||||
* `Qtile <http://docs.qtile.org/>`__
|
||||
* `Quex <http://quex.sourceforge.net/doc/html/main.html>`__
|
||||
* `Satchmo <http://docs.satchmoproject.com/>`__
|
||||
* `Scapy <https://scapy.readthedocs.io/>`__
|
||||
* `SimPy <https://simpy.readthedocs.io/>`__
|
||||
* `six <https://six.readthedocs.io/>`__
|
||||
* `SlamData <https://newdocs.slamdata.com>`__
|
||||
* `Solidity <https://solidity.readthedocs.io/>`__
|
||||
* `Sonos Controller (SoCo) <http://docs.python-soco.com/>`__
|
||||
* `Sphinx AutoAPI <https://sphinx-autoapi.readthedocs.io/>`__
|
||||
* `sphinx-argparse <https://sphinx-argparse.readthedocs.io/>`__
|
||||
* `Sphinx-Gallery <https://sphinx-gallery.readthedocs.io/>`__ (customized)
|
||||
* `SpotBugs <https://spotbugs.readthedocs.io/>`__
|
||||
* `StarUML <https://docs.staruml.io/>`__
|
||||
* `Sublime Text Unofficial Documentation <http://docs.sublimetext.info/>`__
|
||||
* `SunPy <https://docs.sunpy.org/>`__
|
||||
* `Sylius <http://docs.sylius.org/>`__
|
||||
* `Tango Controls <https://tango-controls.readthedocs.io/>`__ (customized)
|
||||
* `Topshelf <http://docs.topshelf-project.com/>`__
|
||||
* `Theano <http://www.deeplearning.net/software/theano/>`__
|
||||
* `ThreatConnect <https://docs.threatconnect.com/>`__
|
||||
* `Tuleap <https://tuleap.net/doc/en/>`__
|
||||
* `TYPO3 <https://docs.typo3.org/>`__ (customized)
|
||||
* `uWSGI <https://uwsgi-docs.readthedocs.io/>`__
|
||||
* `virtualenv <https://virtualenv.readthedocs.io/>`__
|
||||
* `Wagtail <https://docs.wagtail.io/>`__
|
||||
* `Web Application Attack and Audit Framework (w3af) <http://docs.w3af.org/>`__
|
||||
* `Weblate <https://docs.weblate.org/>`__
|
||||
* `x265 <https://x265.readthedocs.io/>`__
|
||||
* `ZeroNet <https://zeronet.readthedocs.io/>`__
|
||||
|
||||
* Blender: https://www.blender.org/api/250PythonDoc/
|
||||
* Blinker: http://discorporate.us/projects/Blinker/docs/
|
||||
* Ceph: http://docs.ceph.com/docs/master/
|
||||
* Classy: http://www.pocoo.org/projects/classy/
|
||||
* DEAP: http://deap.gel.ulaval.ca/doc/0.8/index.html
|
||||
* Django: https://docs.djangoproject.com/
|
||||
* Elemental: http://libelemental.org/documentation/dev/index.html
|
||||
* Enterprise Toolkit for Acrobat products:
|
||||
http://www.adobe.com/devnet-docs/acrobatetk/
|
||||
* e-cidadania: http://e-cidadania.readthedocs.org/en/latest/
|
||||
* Flask: http://flask.pocoo.org/docs/
|
||||
* Flask-OpenID: http://pythonhosted.org/Flask-OpenID/
|
||||
* Gameduino: http://excamera.com/sphinx/gameduino/
|
||||
* GeoServer: http://docs.geoserver.org/
|
||||
* gevent: http://www.gevent.org/
|
||||
* GHC - Glasgow Haskell Compiler: http://downloads.haskell.org/~ghc/master/users-guide/
|
||||
* Glashammer: http://glashammer.org/
|
||||
* Istihza (Turkish Python documentation project): http://belgeler.istihza.com/py2/
|
||||
* Lasso: http://lassoguide.com/
|
||||
* Manage documentation such as source code (fr): http://redaction-technique.org/
|
||||
* MathJax: http://docs.mathjax.org/en/latest/
|
||||
* MirrorBrain: http://mirrorbrain.org/docs/
|
||||
* MyHDL: http://docs.myhdl.org/en/latest/
|
||||
* nose: http://nose.readthedocs.org/en/latest/
|
||||
* NoTex: https://www.notex.ch/overview/
|
||||
* ObjectListView: http://objectlistview.sourceforge.net/python/
|
||||
* Open ERP: https://doc.odoo.com/
|
||||
* OpenCV: http://docs.opencv.org/
|
||||
* Open Dylan: http://opendylan.org/documentation/
|
||||
* OpenLayers: http://docs.openlayers.org/
|
||||
* PyEphem: http://rhodesmill.org/pyephem/
|
||||
* German Plone user manual: http://www.hasecke.com/plone-benutzerhandbuch/
|
||||
* PSI4: http://www.psicode.org/psi4manual/master/index.html
|
||||
* Pylons: http://docs.pylonsproject.org/projects/pylons-webframework/en/latest/
|
||||
* PyMOTW: https://pymotw.com/2/
|
||||
* python-aspectlib: http://python-aspectlib.readthedocs.org/en/latest/
|
||||
(`sphinx-py3doc-enhanced-theme`_)
|
||||
* QGIS: http://qgis.org/en/docs/index.html
|
||||
* qooxdoo: http://manual.qooxdoo.org/current/
|
||||
* Roundup: http://www.roundup-tracker.org/
|
||||
* Seaborn: https://stanford.edu/~mwaskom/software/seaborn/
|
||||
* Selenium: http://docs.seleniumhq.org/docs/
|
||||
* Self: http://www.selflanguage.org/
|
||||
* Substance D: http://docs.pylonsproject.org/projects/substanced/en/latest/
|
||||
* Tablib: http://tablib.org/
|
||||
* SQLAlchemy: http://www.sqlalchemy.org/docs/
|
||||
* tinyTiM: http://tinytim.sourceforge.net/docs/2.0/
|
||||
* Ubuntu packaging guide: http://packaging.ubuntu.com/html/
|
||||
* Werkzeug: http://werkzeug.pocoo.org/docs/
|
||||
* WFront: http://discorporate.us/projects/WFront/
|
||||
Documentation using sphinx_bootstrap_theme
|
||||
------------------------------------------
|
||||
|
||||
.. _sphinx-py3doc-enhanced-theme: https://pypi.python.org/pypi/sphinx_py3doc_enhanced_theme
|
||||
* `Bootstrap Theme <https://ryan-roemer.github.io/sphinx-bootstrap-theme/>`__
|
||||
* `C/C++ Software Development with Eclipse <https://eclipsebook.in/>`__
|
||||
* `Dataverse <http://guides.dataverse.org/>`__
|
||||
* `e-cidadania <https://e-cidadania.readthedocs.io/>`__
|
||||
* `Hangfire <http://docs.hangfire.io/>`__
|
||||
* `Hedge <https://documen.tician.de/hedge/>`__
|
||||
* `ObsPy <https://docs.obspy.org/>`__
|
||||
* `Open Dylan <https://opendylan.org/documentation/>`__
|
||||
* `Pootle <http://docs.translatehouse.org/projects/pootle/>`__
|
||||
* `PyUblas <https://documen.tician.de/pyublas/>`__
|
||||
* `seaborn <https://seaborn.pydata.org/>`__
|
||||
|
||||
Documentation using a custom theme or integrated in a website
|
||||
-------------------------------------------------------------
|
||||
|
||||
* `Apache Cassandra <https://cassandra.apache.org/doc/>`__
|
||||
* `Astropy <http://docs.astropy.org/>`__
|
||||
* `Bokeh <https://bokeh.pydata.org/>`__
|
||||
* `Boto 3 <https://boto3.readthedocs.io/>`__
|
||||
* `CakePHP <https://book.cakephp.org/>`__
|
||||
* `CasperJS <http://docs.casperjs.org/>`__
|
||||
* `Ceph <http://docs.ceph.com/docs/master/>`__
|
||||
* `Chef <https://docs.chef.io/>`__
|
||||
* `CKAN <https://docs.ckan.org/>`__
|
||||
* `Confluent Platform <https://docs.confluent.io/>`__
|
||||
* `Django <https://docs.djangoproject.com/>`__
|
||||
* `Doctrine <https://www.doctrine-project.org/>`__
|
||||
* `Enterprise Toolkit for Acrobat products <https://www.adobe.com/devnet-docs/acrobatetk/>`__
|
||||
* `Gameduino <http://excamera.com/sphinx/gameduino/>`__
|
||||
* `gensim <https://radimrehurek.com/gensim/>`__
|
||||
* `GeoServer <http://docs.geoserver.org/>`__
|
||||
* `gevent <http://www.gevent.org/>`__
|
||||
* `GHC - Glasgow Haskell Compiler <https://downloads.haskell.org/~ghc/master/users-guide/>`__
|
||||
* `Guzzle <http://docs.guzzlephp.org/>`__
|
||||
* `H2O.ai <http://docs.h2o.ai/>`__
|
||||
* `Istihza (Turkish Python documentation project) <https://belgeler.yazbel.com/python-istihza/>`__
|
||||
* `Kombu <http://docs.kombu.me/>`__
|
||||
* `Lasso <http://lassoguide.com/>`__
|
||||
* `Mako <http://docs.makotemplates.org/>`__
|
||||
* `MirrorBrain <http://mirrorbrain.org/docs/>`__
|
||||
* `MongoDB <https://docs.mongodb.com/>`__
|
||||
* `Music21 <https://web.mit.edu/music21/doc/>`__
|
||||
* `MyHDL <http://docs.myhdl.org/>`__
|
||||
* `nose <https://nose.readthedocs.io/>`__
|
||||
* `ns-3 <https://www.nsnam.org/documentation/>`__
|
||||
* `NumPy <https://docs.scipy.org/doc/numpy/reference/>`__
|
||||
* `ObjectListView <http://objectlistview.sourceforge.net/python/>`__
|
||||
* `OpenERP <https://doc.odoo.com/>`__
|
||||
* `OpenCV <https://docs.opencv.org/>`__
|
||||
* `OpenLayers <http://docs.openlayers.org/>`__
|
||||
* `OpenTURNS <https://openturns.github.io/openturns/master/>`__
|
||||
* `Open vSwitch <http://docs.openvswitch.org/>`__
|
||||
* `PlatformIO <https://docs.platformio.org/>`__
|
||||
* `PyEphem <http://rhodesmill.org/pyephem/>`__
|
||||
* `Pygments <http://pygments.org/docs/>`__
|
||||
* `Plone User Manual (German) <https://www.hasecke.com/plone-benutzerhandbuch/4.0/>`__
|
||||
* `PSI4 <http://www.psicode.org/psi4manual/master/index.html>`__
|
||||
* `PyMOTW <https://pymotw.com/2/>`__
|
||||
* `python-aspectlib <https://python-aspectlib.readthedocs.io/>`__ (`sphinx_py3doc_enhanced_theme <https://pypi.org/project/sphinx_py3doc_enhanced_theme/>`__)
|
||||
* `QGIS <https://qgis.org/en/docs/index.html>`__
|
||||
* `qooxdoo <https://www.qooxdoo.org/current/>`__
|
||||
* `Roundup <http://www.roundup-tracker.org/>`__
|
||||
* `SaltStack <https://docs.saltstack.com/>`__
|
||||
* `scikit-learn <http://scikit-learn.org/stable/>`__
|
||||
* `SciPy <https://docs.scipy.org/doc/scipy/refrence/>`__
|
||||
* `Scrapy <https://doc.scrapy.org/>`__
|
||||
* `Seaborn <https://seaborn.pydata.org/>`__
|
||||
* `Selenium <https://docs.seleniumhq.org/docs/>`__
|
||||
* `Self <http://www.selflanguage.org/>`__
|
||||
* `Substance D <https://docs.pylonsproject.org/projects/substanced/>`__
|
||||
* `Sulu <http://docs.sulu.io/>`__
|
||||
* `SQLAlchemy <https://docs.sqlalchemy.org/>`__
|
||||
* `tinyTiM <http://tinytim.sourceforge.net/docs/2.0/>`__
|
||||
* `Twisted <https://twistedmatrix.com/documents/current/>`__
|
||||
* `Ubuntu Packaging Guide <http://packaging.ubuntu.com/html/>`__
|
||||
* `WebFaction <https://docs.webfaction.com/>`__
|
||||
* `WTForms <https://wtforms.readthedocs.io/>`__
|
||||
|
||||
Homepages and other non-documentation sites
|
||||
-------------------------------------------
|
||||
|
||||
* A personal page: http://www.dehlia.in/
|
||||
* Benoit Boissinot: http://bboissin.appspot.com/
|
||||
* lunarsite: http://lunaryorn.de/
|
||||
* The Wine Cellar Book: http://www.thewinecellarbook.com/doc/en/
|
||||
* UC Berkeley Advanced Control Systems course:
|
||||
http://msc.berkeley.edu/tomizuka/me233spring13/
|
||||
* VOR: http://www.vor-cycling.be/
|
||||
|
||||
* `Arizona State University PHY494/PHY598/CHM598 Simulation approaches to Bio-and Nanophysics <https://becksteinlab.physics.asu.edu/pages/courses/2013/SimBioNano/>`__ (classic)
|
||||
* `Benoit Boissinot <https://bboissin.appspot.com/>`__ (classic, customized)
|
||||
* `Computer Networks, Parallelization, and Simulation Laboratory (CNPSLab) <https://lab.miletic.net/>`__ (sphinx_rtd_theme)
|
||||
* `Deep Learning Tutorials <http://www.deeplearning.net/tutorial/>`__ (sphinxdoc)
|
||||
* `Eric Holscher <http://ericholscher.com/>`__ (alabaster)
|
||||
* `Lei Ma's Statistical Mechanics lecture notes <http://statisticalphysics.openmetric.org/>`__ (sphinx_bootstrap_theme)
|
||||
* `Loyola University Chicago COMP 339-439 Distributed Systems course <https://books.cs.luc.edu/distributedsystems/>`__ (sphinx_bootstrap_theme)
|
||||
* `Pylearn2 <http://www.deeplearning.net/software/pylearn2/>`__ (sphinxdoc, customized)
|
||||
* `PyXLL <https://www.pyxll.com/>`__ (sphinx_bootstrap_theme, customized)
|
||||
* `SciPy Cookbook <https://scipy-cookbook.readthedocs.io/>`__ (sphinx_rtd_theme)
|
||||
* `The Wine Cellar Book <https://www.thewinecellarbook.com/doc/en/>`__ (sphinxdoc)
|
||||
* `Thomas Cokelaer's Python, Sphinx and reStructuredText tutorials <https://thomas-cokelaer.info/tutorials/>`__ (standard)
|
||||
* `UC Berkeley ME233 Advanced Control Systems II course <https://berkeley-me233.github.io/>`__ (sphinxdoc)
|
||||
* `Željko Svedružić's Biomolecular Structure and Function Laboratory (BioSFLab) <https://www.svedruziclab.com/>`__ (sphinx_bootstrap_theme)
|
||||
|
||||
Books produced using Sphinx
|
||||
---------------------------
|
||||
|
||||
* "The ``repoze.bfg`` Web Application Framework":
|
||||
http://www.amazon.com/repoze-bfg-Web-Application-Framework-Version/dp/0615345379
|
||||
* A Theoretical Physics Reference book: http://www.theoretical-physics.net/
|
||||
* "Simple and Steady Way of Learning for Software Engineering" (in Japanese):
|
||||
http://www.amazon.co.jp/dp/477414259X/
|
||||
* "Expert Python Programming":
|
||||
https://www.packtpub.com/application-development/expert-python-programming
|
||||
* "Expert Python Programming" (Japanese translation):
|
||||
http://www.amazon.co.jp/dp/4048686291/
|
||||
* "Pomodoro Technique Illustrated" (Japanese translation):
|
||||
http://www.amazon.co.jp/dp/4048689525/
|
||||
* "Python Professional Programming" (in Japanese):
|
||||
http://www.amazon.co.jp/dp/4798032948/
|
||||
* "Die Wahrheit des Sehens. Der DEKALOG von Krzysztof Kieślowski":
|
||||
http://www.hasecke.eu/Dekalog/
|
||||
* The "Varnish Book":
|
||||
http://book.varnish-software.com/4.0/
|
||||
* "Learning Sphinx" (in Japanese):
|
||||
http://www.oreilly.co.jp/books/9784873116488/
|
||||
* "LassoGuide":
|
||||
http://www.lassosoft.com/Lasso-Documentation
|
||||
* "Software-Dokumentation mit Sphinx": http://www.amazon.de/dp/1497448689/
|
||||
* `"The Art of Community" (Japanese translation) <https://www.oreilly.co.jp/books/9784873114958/>`__
|
||||
* `"Die Wahrheit des Sehens. Der DEKALOG von Krzysztof Kieślowski" <https://literatur.hasecke.com/post/die-wahrheit-des-sehens-dekalog-kieslowski/>`__
|
||||
* `"Expert Python Programming" <https://www.packtpub.com/application-development/expert-python-programming>`__
|
||||
* `"Expert Python Programming" (Japanese translation) <https://www.amazon.co.jp/dp/4048686291/>`__
|
||||
* `"Expert Python Programming 2nd Edition" (Japanese translation) <https://www.amazon.co.jp/dp/4048930613/>`__
|
||||
* `"The Hitchhiker's Guide to Python" <https://docs.python-guide.org/>`__
|
||||
* `"LassoGuide" <http://www.lassosoft.com/Lasso-Documentation>`__
|
||||
* `"Learning Sphinx" (in Japanese) <https://www.oreilly.co.jp/books/9784873116488/>`__
|
||||
* `"Learning System Programming with Go (Japanese)" <https://www.lambdanote.com/products/go>`__
|
||||
* `"Mercurial: the definitive guide (Second edition)" <https://book.mercurial-scm.org/>`__
|
||||
* `"Mithril -- The fastest clientside MVC (Japanese)" <https://www.oreilly.co.jp/books/9784873117447/>`__
|
||||
* `"Pioneers and Prominent Men of Utah" <http://pioneers.rstebbing.com/>`__
|
||||
* `"Pomodoro Technique Illustrated" (Japanese translation) <https://www.amazon.co.jp/dp/4048689525/>`__
|
||||
* `"Python Professional Programming" (in Japanese) <http://www.amazon.co.jp/dp/4798032948/>`__
|
||||
* `"Python Professional Programming 2nd Edition" (in Japanese) <https://www.amazon.co.jp/dp/479804315X/>`__
|
||||
* `"Python Professional Programming 3rd Edition" (in Japanese) <https://www.amazon.co.jp/dp/4798053821/>`__
|
||||
* `"Real World HTTP -- Learning The Internet and Web Technology via its history and code (Japanese)" <https://www.oreilly.co.jp/books/9784873118048/>`__
|
||||
* `"Redmine Primer 5th Edition (in Japanese)" <https://www.shuwasystem.co.jp/products/7980html/4825.html>`__
|
||||
* `"The repoze.bfg Web Application Framework" <https://www.amazon.com/repoze-bfg-Web-Application-Framework-Version/dp/0615345379>`__
|
||||
* `"The Self-Taught Programmer" (Japanese translation) <https://www.amazon.co.jp/dp/4822292274/>`__
|
||||
* `"Simple and Steady Way of Learning for Software Engineering" (in Japanese) <https://www.amazon.co.jp/dp/477414259X/>`__
|
||||
* `"Software-Dokumentation mit Sphinx" <https://www.amazon.de/dp/1497448689/>`__
|
||||
* `"Theoretical Physics Reference" <https://www.theoretical-physics.net/>`__
|
||||
* `"The Varnish Book" <https://info.varnish-software.com/the-varnish-book>`__
|
||||
|
||||
Theses produced using Sphinx
|
||||
----------------------------
|
||||
|
||||
Thesis using Sphinx
|
||||
-------------------
|
||||
* `"A Web-Based System for Comparative Analysis of OpenStreetMap Data by the Use
|
||||
of CouchDB" <https://www.yumpu.com/et/document/view/11722645/masterthesis-markusmayr-0542042>`__
|
||||
* `"Content Conditioning and Distribution for Dynamic Virtual Worlds" <https://www.cs.princeton.edu/research/techreps/TR-941-12>`__
|
||||
* `"The Sphinx Thesis Resource" <https://jterrace.github.io/sphinxtr/>`__
|
||||
|
||||
* "A Web-Based System for Comparative Analysis of OpenStreetMap Data
|
||||
by the Use of CouchDB":
|
||||
https://www.yumpu.com/et/document/view/11722645/masterthesis-markusmayr-0542042
|
||||
Projects integrating Sphinx functionality
|
||||
-----------------------------------------
|
||||
|
||||
* `Read the Docs <https://readthedocs.org/>`__, a software-as-a-service documentation hosting platform, uses
|
||||
Sphinx to automatically build documentation updates that are pushed to GitHub.
|
||||
|
||||
* `Spyder <https://docs.spyder-ide.org/help.html>`__, the Scientific Python Development Environment, uses Sphinx in its
|
||||
help pane to render rich documentation for functions, classes and methods
|
||||
automatically or on-demand.
|
||||
@@ -1,7 +1,7 @@
|
||||
License for Sphinx
|
||||
==================
|
||||
|
||||
Copyright (c) 2007-2017 by the Sphinx team (see AUTHORS file).
|
||||
Copyright (c) 2007-2018 by the Sphinx team (see AUTHORS file).
|
||||
All rights reserved.
|
||||
|
||||
Redistribution and use in source and binary forms, with or without
|
||||
@@ -31,64 +31,6 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
||||
Licenses for incorporated software
|
||||
==================================
|
||||
|
||||
The pgen2 package, included in this distribution under the name
|
||||
sphinx.pycode.pgen2, is available in the Python 2.6 distribution under
|
||||
the PSF license agreement for Python:
|
||||
|
||||
----------------------------------------------------------------------
|
||||
Copyright © 2001-2008 Python Software Foundation; All Rights Reserved.
|
||||
|
||||
PYTHON SOFTWARE FOUNDATION LICENSE VERSION 2
|
||||
--------------------------------------------
|
||||
|
||||
1. This LICENSE AGREEMENT is between the Python Software Foundation
|
||||
("PSF"), and the Individual or Organization ("Licensee") accessing
|
||||
and otherwise using Python 2.6 software in source or binary form
|
||||
and its associated documentation.
|
||||
|
||||
2. Subject to the terms and conditions of this License Agreement, PSF
|
||||
hereby grants Licensee a nonexclusive, royalty-free, world-wide
|
||||
license to reproduce, analyze, test, perform and/or display
|
||||
publicly, prepare derivative works, distribute, and otherwise use
|
||||
Python 2.6 alone or in any derivative version, provided, however,
|
||||
that PSF's License Agreement and PSF's notice of copyright, i.e.,
|
||||
"Copyright © 2001-2008 Python Software Foundation; All Rights
|
||||
Reserved" are retained in Python 2.6 alone or in any derivative
|
||||
version prepared by Licensee.
|
||||
|
||||
3. In the event Licensee prepares a derivative work that is based on
|
||||
or incorporates Python 2.6 or any part thereof, and wants to make
|
||||
the derivative work available to others as provided herein, then
|
||||
Licensee hereby agrees to include in any such work a brief summary
|
||||
of the changes made to Python 2.6.
|
||||
|
||||
4. PSF is making Python 2.6 available to Licensee on an "AS IS" basis.
|
||||
PSF MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY
|
||||
WAY OF EXAMPLE, BUT NOT LIMITATION, PSF MAKES NO AND DISCLAIMS ANY
|
||||
REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY
|
||||
PARTICULAR PURPOSE OR THAT THE USE OF PYTHON 2.6 WILL NOT INFRINGE
|
||||
ANY THIRD PARTY RIGHTS.
|
||||
|
||||
5. PSF SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF PYTHON
|
||||
2.6 FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS
|
||||
AS A RESULT OF MODIFYING, DISTRIBUTING, OR OTHERWISE USING PYTHON
|
||||
2.6, OR ANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY
|
||||
THEREOF.
|
||||
|
||||
6. This License Agreement will automatically terminate upon a material
|
||||
breach of its terms and conditions.
|
||||
|
||||
7. Nothing in this License Agreement shall be deemed to create any
|
||||
relationship of agency, partnership, or joint venture between PSF
|
||||
and Licensee. This License Agreement does not grant permission to
|
||||
use PSF trademarks or trade name in a trademark sense to endorse or
|
||||
promote products or services of Licensee, or any third party.
|
||||
|
||||
8. By copying, installing or otherwise using Python 2.6, Licensee
|
||||
agrees to be bound by the terms and conditions of this License
|
||||
Agreement.
|
||||
----------------------------------------------------------------------
|
||||
|
||||
The included smartypants module, included as sphinx.util.smartypants,
|
||||
is available under the following license:
|
||||
|
||||
@@ -162,36 +104,6 @@ smartypants.py license::
|
||||
such damage.
|
||||
----------------------------------------------------------------------
|
||||
|
||||
The ElementTree package, included in this distribution in
|
||||
test/etree13, is available under the following license:
|
||||
|
||||
----------------------------------------------------------------------
|
||||
The ElementTree toolkit is
|
||||
|
||||
Copyright (c) 1999-2007 by Fredrik Lundh
|
||||
|
||||
By obtaining, using, and/or copying this software and/or its
|
||||
associated documentation, you agree that you have read, understood,
|
||||
and will comply with the following terms and conditions:
|
||||
|
||||
Permission to use, copy, modify, and distribute this software and its
|
||||
associated documentation for any purpose and without fee is hereby
|
||||
granted, provided that the above copyright notice appears in all
|
||||
copies, and that both that copyright notice and this permission notice
|
||||
appear in supporting documentation, and that the name of Secret Labs
|
||||
AB or the author not be used in advertising or publicity pertaining to
|
||||
distribution of the software without specific, written prior
|
||||
permission.
|
||||
|
||||
SECRET LABS AB AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO
|
||||
THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANT- ABILITY
|
||||
AND FITNESS. IN NO EVENT SHALL SECRET LABS AB OR THE AUTHOR BE LIABLE
|
||||
FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
|
||||
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
|
||||
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
|
||||
OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
|
||||
----------------------------------------------------------------------
|
||||
|
||||
The included JQuery JavaScript library is available under the MIT
|
||||
license:
|
||||
|
||||
|
||||
+1
-3
@@ -12,20 +12,18 @@ include sphinx-autogen.py
|
||||
include sphinx-build.py
|
||||
include sphinx-quickstart.py
|
||||
include sphinx-apidoc.py
|
||||
include test-reqs.txt
|
||||
include tox.ini
|
||||
include sphinx/locale/.tx/config
|
||||
|
||||
recursive-include sphinx/templates *
|
||||
recursive-include sphinx/texinputs *
|
||||
recursive-include sphinx/texinputs_win *
|
||||
recursive-include sphinx/themes *
|
||||
recursive-include sphinx/pycode/pgen2 *.c *.pyx
|
||||
recursive-include sphinx/locale *.js *.pot *.po *.mo
|
||||
recursive-include sphinx/search/non-minified-js *.js
|
||||
recursive-include sphinx/ext/autosummary/templates *
|
||||
recursive-include tests *
|
||||
recursive-include utils *
|
||||
include sphinx/pycode/Grammar-py*
|
||||
|
||||
recursive-include doc *
|
||||
prune doc/_build
|
||||
|
||||
@@ -1,67 +1,33 @@
|
||||
PYTHON ?= python
|
||||
|
||||
.PHONY: all style-check type-check clean clean-pyc clean-patchfiles clean-backupfiles \
|
||||
clean-generated pylint reindent test covertest build
|
||||
|
||||
DONT_CHECK = -i .ropeproject \
|
||||
-i .tox \
|
||||
-i build \
|
||||
-i dist \
|
||||
-i doc/_build \
|
||||
-i sphinx/pycode/pgen2 \
|
||||
-i sphinx/search/da.py \
|
||||
-i sphinx/search/de.py \
|
||||
-i sphinx/search/en.py \
|
||||
-i sphinx/search/es.py \
|
||||
-i sphinx/search/fi.py \
|
||||
-i sphinx/search/fr.py \
|
||||
-i sphinx/search/hu.py \
|
||||
-i sphinx/search/it.py \
|
||||
-i sphinx/search/ja.py \
|
||||
-i sphinx/search/nl.py \
|
||||
-i sphinx/search/no.py \
|
||||
-i sphinx/search/pt.py \
|
||||
-i sphinx/search/ro.py \
|
||||
-i sphinx/search/ru.py \
|
||||
-i sphinx/search/sv.py \
|
||||
-i sphinx/search/tr.py \
|
||||
-i sphinx/style/jquery.js \
|
||||
-i sphinx/util/smartypants.py \
|
||||
-i tests/build \
|
||||
-i tests/path.py \
|
||||
-i tests/roots/test-directive-code/target.py \
|
||||
-i tests/roots/test-warnings/undecodable.rst \
|
||||
-i tests/test_autodoc_py35.py \
|
||||
-i tests/typing_test_data.py \
|
||||
-i utils/convert.py
|
||||
PYTHON ?= python3
|
||||
|
||||
.PHONY: all
|
||||
all: clean-pyc clean-backupfiles style-check type-check test
|
||||
|
||||
style-check:
|
||||
@PYTHONWARNINGS=all $(PYTHON) utils/check_sources.py $(DONT_CHECK) .
|
||||
|
||||
type-check:
|
||||
mypy sphinx/
|
||||
|
||||
.PHONY: clean
|
||||
clean: clean-pyc clean-pycache clean-patchfiles clean-backupfiles clean-generated clean-testfiles clean-buildfiles clean-mypyfiles
|
||||
|
||||
.PHONY: clean-pyc
|
||||
clean-pyc:
|
||||
find . -name '*.pyc' -exec rm -f {} +
|
||||
find . -name '*.pyo' -exec rm -f {} +
|
||||
|
||||
.PHONY: clean-pycache
|
||||
clean-pycache:
|
||||
find . -name __pycache__ -exec rm -rf {} +
|
||||
|
||||
.PHONY: clean-patchfiles
|
||||
clean-patchfiles:
|
||||
find . -name '*.orig' -exec rm -f {} +
|
||||
find . -name '*.rej' -exec rm -f {} +
|
||||
|
||||
.PHONY: clean-backupfiles
|
||||
clean-backupfiles:
|
||||
find . -name '*~' -exec rm -f {} +
|
||||
find . -name '*.bak' -exec rm -f {} +
|
||||
find . -name '*.swp' -exec rm -f {} +
|
||||
find . -name '*.swo' -exec rm -f {} +
|
||||
|
||||
.PHONY: clean-generated
|
||||
clean-generated:
|
||||
find . -name '.DS_Store' -exec rm -f {} +
|
||||
rm -rf Sphinx.egg-info/
|
||||
@@ -70,32 +36,48 @@ clean-generated:
|
||||
rm -f utils/*3.py*
|
||||
rm -f utils/regression_test.js
|
||||
|
||||
.PHONY: clean-testfiles
|
||||
clean-testfiles:
|
||||
rm -rf tests/.coverage
|
||||
rm -rf tests/build
|
||||
rm -rf .tox/
|
||||
rm -rf .cache/
|
||||
|
||||
.PHONY: clean-buildfiles
|
||||
clean-buildfiles:
|
||||
rm -rf build
|
||||
|
||||
.PHONY: clean-mypyfiles
|
||||
clean-mypyfiles:
|
||||
rm -rf .mypy_cache/
|
||||
|
||||
.PHONY: style-check
|
||||
style-check:
|
||||
@flake8
|
||||
|
||||
.PHONY: type-check
|
||||
type-check:
|
||||
mypy sphinx
|
||||
|
||||
.PHONY: pylint
|
||||
pylint:
|
||||
@pylint --rcfile utils/pylintrc sphinx
|
||||
|
||||
reindent:
|
||||
@$(PYTHON) utils/reindent.py -r -n .
|
||||
|
||||
.PHONY: test
|
||||
test:
|
||||
@cd tests; $(PYTHON) run.py --ignore py35 -v $(TEST)
|
||||
|
||||
test-async:
|
||||
@cd tests; $(PYTHON) run.py -v $(TEST)
|
||||
@$(PYTHON) -m pytest -v $(TEST)
|
||||
|
||||
.PHONY: covertest
|
||||
covertest:
|
||||
@cd tests; $(PYTHON) run.py -v --cov=sphinx --junitxml=.junit.xml $(TEST)
|
||||
@$(PYTHON) -m pytest -v --cov=sphinx --junitxml=.junit.xml $(TEST)
|
||||
|
||||
.PHONY: build
|
||||
build:
|
||||
@$(PYTHON) setup.py build
|
||||
|
||||
.PHONY: docs
|
||||
docs:
|
||||
ifndef target
|
||||
$(info You need to give a provide a target variable, e.g. `make docs target=html`.)
|
||||
endif
|
||||
$(MAKE) -C doc $(target)
|
||||
+88
-52
@@ -1,45 +1,115 @@
|
||||
========
|
||||
Sphinx
|
||||
========
|
||||
|
||||
.. image:: https://img.shields.io/pypi/v/sphinx.svg
|
||||
:target: https://pypi.python.org/pypi/Sphinx
|
||||
.. image:: https://readthedocs.org/projects/sphinx/badge/
|
||||
:target: https://pypi.org/project/Sphinx/
|
||||
:alt: Package on PyPI
|
||||
|
||||
.. image:: https://readthedocs.org/projects/sphinx/badge/?version=master
|
||||
:target: http://www.sphinx-doc.org/
|
||||
:alt: Documentation Status
|
||||
|
||||
.. image:: https://travis-ci.org/sphinx-doc/sphinx.svg?branch=master
|
||||
:target: https://travis-ci.org/sphinx-doc/sphinx
|
||||
:alt: Build Status (Travis CI)
|
||||
|
||||
=================
|
||||
README for Sphinx
|
||||
=================
|
||||
.. image:: https://ci.appveyor.com/api/projects/status/github/sphinx-doc/sphinx?branch=master&svg=true
|
||||
:target: https://ci.appveyor.com/project/sphinxdoc/sphinx
|
||||
:alt: Build Status (AppVeyor)
|
||||
|
||||
This is the Sphinx documentation generator, see http://www.sphinx-doc.org/.
|
||||
.. image:: https://circleci.com/gh/sphinx-doc/sphinx.svg?style=shield
|
||||
:target: https://circleci.com/gh/sphinx-doc/sphinx
|
||||
:alt: Build Status (CircleCI)
|
||||
|
||||
.. image:: https://codecov.io/gh/sphinx-doc/sphinx/branch/master/graph/badge.svg
|
||||
:target: https://codecov.io/gh/sphinx-doc/sphinx
|
||||
:alt: Code Coverage Status (Codecov)
|
||||
|
||||
Installing
|
||||
==========
|
||||
Sphinx is a tool that makes it easy to create intelligent and beautiful
|
||||
documentation for Python projects (or other documents consisting of multiple
|
||||
reStructuredText sources), written by Georg Brandl. It was originally created
|
||||
for the new Python documentation, and has excellent facilities for Python
|
||||
project documentation, but C/C++ is supported as well, and more languages are
|
||||
planned.
|
||||
|
||||
Install from PyPI to use stable version::
|
||||
Sphinx uses reStructuredText as its markup language, and many of its strengths
|
||||
come from the power and straightforwardness of reStructuredText and its parsing
|
||||
and translating suite, the Docutils.
|
||||
|
||||
Among its features are the following:
|
||||
|
||||
* Output formats: HTML (including derivative formats such as HTML Help, Epub
|
||||
and Qt Help), plain text, manual pages and LaTeX or direct PDF output
|
||||
using rst2pdf
|
||||
* Extensive cross-references: semantic markup and automatic links
|
||||
for functions, classes, glossary terms and similar pieces of information
|
||||
* Hierarchical structure: easy definition of a document tree, with automatic
|
||||
links to siblings, parents and children
|
||||
* Automatic indices: general index as well as a module index
|
||||
* Code handling: automatic highlighting using the Pygments highlighter
|
||||
* Flexible HTML output using the Jinja 2 templating engine
|
||||
* Various extensions are available, e.g. for automatic testing of snippets
|
||||
and inclusion of appropriately formatted docstrings
|
||||
* Setuptools integration
|
||||
|
||||
For more information, refer to the `the documentation`__.
|
||||
|
||||
.. __: http://www.sphinx-doc.org/
|
||||
|
||||
Installation
|
||||
============
|
||||
|
||||
Sphinx is published on `PyPI`__ and can be installed from there::
|
||||
|
||||
pip install -U sphinx
|
||||
|
||||
Install from PyPI to use beta version::
|
||||
We also publish beta releases::
|
||||
|
||||
pip install -U --pre sphinx
|
||||
|
||||
Install from newest dev version in stable branch::
|
||||
If you wish to install `Sphinx` for development purposes, refer to `the
|
||||
contributors guide`__.
|
||||
|
||||
pip install git+https://github.com/sphinx-doc/sphinx@stable
|
||||
__ https://pypi.org/project/Sphinx/
|
||||
__ http://www.sphinx-doc.org/en/master/devguide.html
|
||||
|
||||
Install from newest dev version in master branch::
|
||||
Documentation
|
||||
=============
|
||||
|
||||
pip install git+https://github.com/sphinx-doc/sphinx
|
||||
Documentation is available from `sphinx-doc.org`__.
|
||||
|
||||
Install from cloned source::
|
||||
__ http://www.sphinx-doc.org/
|
||||
|
||||
pip install .
|
||||
Get in touch
|
||||
============
|
||||
|
||||
Install from cloned source as editable::
|
||||
- Report bugs, suggest features or view the source code `on GitHub`_.
|
||||
- For less well defined questions or ideas, use the `mailing list`_.
|
||||
|
||||
pip install -e .
|
||||
.. _on GitHub: https://github.com/sphinx-doc/sphinx
|
||||
.. _mailing list: https://groups.google.com/forum/#!forum/sphinx-users
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
Continuous testing is provided by `Travis`__ (for unit tests and style checks
|
||||
on Linux), `AppVeyor`__ (for unit tests on Windows), and `CircleCI`__ (for
|
||||
large processes like TeX compilation).
|
||||
|
||||
For information on running tests locally, refer to `the contributors guide`__.
|
||||
|
||||
__ https://travis-ci.org/sphinx-doc/sphinx
|
||||
__ https://ci.appveyor.com/project/sphinxdoc/sphinx
|
||||
__ https://circleci.com/gh/sphinx-doc/sphinx
|
||||
__ http://www.sphinx-doc.org/en/master/devguide.html
|
||||
|
||||
Contributing
|
||||
============
|
||||
|
||||
Refer to `the contributors guide`__.
|
||||
|
||||
__ http://www.sphinx-doc.org/en/master/devguide.html
|
||||
|
||||
Release signatures
|
||||
==================
|
||||
@@ -48,37 +118,3 @@ Releases are signed with following keys:
|
||||
|
||||
* `498D6B9E <https://pgp.mit.edu/pks/lookup?op=vindex&search=0x102C2C17498D6B9E>`_
|
||||
* `5EBA0E07 <https://pgp.mit.edu/pks/lookup?op=vindex&search=0x1425F8CE5EBA0E07>`_
|
||||
|
||||
Reading the docs
|
||||
================
|
||||
|
||||
You can read them online at <http://www.sphinx-doc.org/>.
|
||||
|
||||
Or, after installing::
|
||||
|
||||
cd doc
|
||||
make html
|
||||
|
||||
Then, direct your browser to ``_build/html/index.html``.
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
To run the tests with the interpreter available as ``python``, use::
|
||||
|
||||
make test
|
||||
|
||||
If you want to use a different interpreter, e.g. ``python3``, use::
|
||||
|
||||
PYTHON=python3 make test
|
||||
|
||||
Continuous testing runs on travis: https://travis-ci.org/sphinx-doc/sphinx
|
||||
|
||||
|
||||
Contributing
|
||||
============
|
||||
|
||||
See `CONTRIBUTING.rst`__
|
||||
|
||||
.. __: CONTRIBUTING.rst
|
||||
|
||||
+2
-1
@@ -1,9 +1,10 @@
|
||||
# Makefile for Sphinx documentation
|
||||
#
|
||||
PYTHON ?= python3
|
||||
|
||||
# You can set these variables from the command line.
|
||||
SPHINXOPTS =
|
||||
SPHINXBUILD = python ../sphinx-build.py
|
||||
SPHINXBUILD = $(PYTHON) ../sphinx/cmd/build.py
|
||||
SPHINXPROJ = sphinx
|
||||
SOURCEDIR = .
|
||||
BUILDDIR = _build
|
||||
|
||||
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
Vendored
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
File renamed without changes.
Vendored
+5
-8
@@ -49,7 +49,7 @@
|
||||
<table class="contentstable">
|
||||
<tr>
|
||||
<td>
|
||||
<p class="biglink"><a class="biglink" href="{{ pathto("tutorial") }}">{%trans%}First steps with Sphinx{%endtrans%}</a><br/>
|
||||
<p class="biglink"><a class="biglink" href="{{ pathto("usage/quickstart") }}">{%trans%}First steps with Sphinx{%endtrans%}</a><br/>
|
||||
<span class="linkdescr">{%trans%}overview of basic tasks{%endtrans%}</span></p>
|
||||
</td><td>
|
||||
{%- if hasdoc('search') %}<p class="biglink"><a class="biglink" href="{{ pathto("search") }}">{%trans%}Search page{%endtrans%}</a><br/>
|
||||
@@ -73,11 +73,8 @@
|
||||
</table>
|
||||
|
||||
<p>{%trans%}
|
||||
You can also download PDF/EPUB versions of the Sphinx documentation:
|
||||
a <a href="http://readthedocs.org/projects/sphinx/downloads/pdf/stable/">PDF version</a> generated from
|
||||
the LaTeX Sphinx produces, and
|
||||
a <a href="http://readthedocs.org/projects/sphinx/downloads/epub/stable/">EPUB version</a>.
|
||||
{%endtrans%}
|
||||
You can also download PDF/EPUB versions of the Sphinx documentation
|
||||
from pop up menu on lower right corner.{%endtrans%}
|
||||
</p>
|
||||
|
||||
<h2>{%trans%}Examples{%endtrans%}</h2>
|
||||
@@ -98,7 +95,7 @@
|
||||
<p>{%trans%}There is a <a href="http://docs.sphinx-users.jp/">Japanese translation</a>
|
||||
of this documentation, thanks to the Japanese Sphinx user group.{%endtrans%}</p>
|
||||
<p>{%trans%}A Japanese book about Sphinx has been published by O'Reilly:
|
||||
<a href="http://www.oreilly.co.jp/books/9784873116488/">Sphinxをはじめよう /
|
||||
<a href="https://www.oreilly.co.jp/books/9784873116488/">Sphinxをはじめよう /
|
||||
Learning Sphinx</a>.{%endtrans%}</p>
|
||||
<!-- <p><img src="{{ pathto("_static/bookcover.png", 1) }}"/></p> -->
|
||||
|
||||
@@ -106,7 +103,7 @@
|
||||
<h2>{%trans%}Hosting{%endtrans%}</h2>
|
||||
|
||||
<p>{%trans%}Need a place to host your Sphinx docs?
|
||||
<a href="http://readthedocs.org">readthedocs.org</a> hosts a lot of Sphinx docs
|
||||
<a href="https://readthedocs.org/">readthedocs.org</a> hosts a lot of Sphinx docs
|
||||
already, and integrates well with projects' source control. It also features a
|
||||
powerful built-in search that exceeds the possibilities of Sphinx' JavaScript-based
|
||||
offline search.{%endtrans%}</p>
|
||||
|
||||
Vendored
+11
-19
@@ -1,31 +1,23 @@
|
||||
<p class="logo">A <a href="http://pocoo.org/">
|
||||
<p class="logo">A <a href="https://www.pocoo.org/">
|
||||
<img src="{{ pathto("_static/pocoo.png", 1) }}" alt="Pocoo" /></a>
|
||||
{%trans%}project{%endtrans%}</p>
|
||||
|
||||
<h3>Download</h3>
|
||||
{% if version.endswith('+') %}
|
||||
<p>{%trans%}This documentation is for version <b><a href="changes.html">{{ version }}</a></b>, which is
|
||||
not released yet.{%endtrans%}</p>
|
||||
<p>{%trans%}You can use it from the
|
||||
<a href="https://github.com/sphinx-doc/sphinx/">Git repo</a> or look for
|
||||
released versions in the <a href="https://pypi.python.org/pypi/Sphinx">Python
|
||||
Package Index</a>.{%endtrans%}</p>
|
||||
{% else %}
|
||||
<p>{%trans%}Current version: <b><a href="changes.html">{{ version }}</a></b>{%endtrans%}</p>
|
||||
<p>{%trans%}Get Sphinx from the <a href="https://pypi.python.org/pypi/Sphinx">Python Package
|
||||
Index</a>, or install it with:{%endtrans%}</p>
|
||||
<p class="download">{%trans%}Current version: <a href="https://pypi.org/project/Sphinx/" alt="PyPI"><img src="https://img.shields.io/pypi/v/sphinx.svg"></a>{%endtrans%}</p>
|
||||
<p>{%trans%}Install Sphinx with:{%endtrans%}</p>
|
||||
<pre>pip install -U Sphinx</pre>
|
||||
{% endif %}
|
||||
|
||||
<h3>{%trans%}Questions? Suggestions?{%endtrans%}</h3>
|
||||
|
||||
<p>{%trans%}Join the <a href="http://groups.google.com/group/sphinx-users">sphinx-users</a> mailing list on Google Groups:{%endtrans%}</p>
|
||||
<form action="http://groups.google.com/group/sphinx-users/boxsubscribe"
|
||||
style="padding-left: 0.5em">
|
||||
<input type="text" name="email" value="your@email" style="font-size: 90%; width: 120px"
|
||||
onfocus="$(this).val('');"/>
|
||||
<input type="submit" name="sub" value="Subscribe" style="font-size: 90%; width: 70px"/>
|
||||
<p>{%trans%}Join the <a href="https://groups.google.com/group/sphinx-users">sphinx-users</a> mailing list on Google Groups:{%endtrans%}</p>
|
||||
<div class="subscribeformwrapper">
|
||||
<form action="https://groups.google.com/group/sphinx-users/boxsubscribe"
|
||||
class="subscribeform">
|
||||
<input type="text" name="email" value="your@email"
|
||||
onfocus="$(this).val('');" />
|
||||
<input type="submit" name="sub" value="Subscribe" />
|
||||
</form>
|
||||
</div>
|
||||
<p>{%trans%}or come to the <tt>#sphinx-doc</tt> channel on FreeNode.{%endtrans%}</p>
|
||||
<p>{%trans%}You can also open an issue at the
|
||||
<a href="https://github.com/sphinx-doc/sphinx/issues">tracker</a>.{%endtrans%}</p>
|
||||
Vendored
+8
-3
@@ -4,7 +4,7 @@
|
||||
|
||||
Sphinx layout template for the sphinxdoc theme.
|
||||
|
||||
:copyright: Copyright 2007-2017 by the Sphinx team, see AUTHORS.
|
||||
:copyright: Copyright 2007-2018 by the Sphinx team, see AUTHORS.
|
||||
:license: BSD, see LICENSE for details.
|
||||
#}
|
||||
{%- extends "basic/layout.html" %}
|
||||
@@ -13,8 +13,13 @@
|
||||
{% block sidebar1 %}{{ sidebar() }}{% endblock %}
|
||||
{% block sidebar2 %}{% endblock %}
|
||||
|
||||
{% block linktags %}
|
||||
{{ super() }}
|
||||
<link rel="canonical" href="http://www.sphinx-doc.org/en/master/{{ pagename }}{{ file_suffix }}" />
|
||||
{% endblock %}
|
||||
|
||||
{% block extrahead %}
|
||||
<link href='http://fonts.googleapis.com/css?family=Open+Sans:300,400,700'
|
||||
<link href='https://fonts.googleapis.com/css?family=Open+Sans:300,400,700'
|
||||
rel='stylesheet' type='text/css' />
|
||||
{{ super() }}
|
||||
{%- if not embedded %}
|
||||
@@ -65,7 +70,7 @@
|
||||
<div class="pageheader">
|
||||
<ul>
|
||||
<li><a href="{{ pathto('index') }}">Home</a></li>
|
||||
<li><a href="{{ pathto('install') }}">Get it</a></li>
|
||||
<li><a href="{{ pathto('usage/installation') }}">Get it</a></li>
|
||||
<li><a href="{{ pathto('contents') }}">Docs</a></li>
|
||||
<li><a href="{{ pathto('develop') }}">Extend/Develop</a></li>
|
||||
</ul>
|
||||
|
||||
+37
-3
@@ -4,7 +4,7 @@
|
||||
*
|
||||
* Sphinx stylesheet -- sphinx13 theme.
|
||||
*
|
||||
* :copyright: Copyright 2007-2017 by the Sphinx team, see AUTHORS.
|
||||
* :copyright: Copyright 2007-2018 by the Sphinx team, see AUTHORS.
|
||||
* :license: BSD, see LICENSE for details.
|
||||
*
|
||||
*/
|
||||
@@ -140,11 +140,41 @@ div.sphinxsidebar .logo img {
|
||||
vertical-align: middle;
|
||||
}
|
||||
|
||||
div.sphinxsidebar .download a img {
|
||||
vertical-align: middle;
|
||||
}
|
||||
|
||||
div.subscribeformwrapper {
|
||||
display: block;
|
||||
overflow: auto;
|
||||
margin-bottom: 1.2em;
|
||||
}
|
||||
|
||||
div.sphinxsidebar input {
|
||||
border: 1px solid #aaa;
|
||||
font-family: 'Open Sans', 'Lucida Grande', 'Lucida Sans Unicode', 'Geneva',
|
||||
'Verdana', sans-serif;
|
||||
font-size: 1em;
|
||||
}
|
||||
|
||||
div.sphinxsidebar .subscribeform {
|
||||
margin-top: 0;
|
||||
}
|
||||
|
||||
div.sphinxsidebar .subscribeform input {
|
||||
border: 1px solid #aaa;
|
||||
font-size: 0.9em;
|
||||
float: left;
|
||||
padding: 0.25em 0.5em;
|
||||
box-sizing: border-box;
|
||||
}
|
||||
|
||||
div.sphinxsidebar .subscribeform input[type="text"] {
|
||||
width: 60%;
|
||||
}
|
||||
|
||||
div.sphinxsidebar .subscribeform input[type="submit"] {
|
||||
width: 40%;
|
||||
border-left: none;
|
||||
}
|
||||
|
||||
div.sphinxsidebar h3 {
|
||||
@@ -276,12 +306,16 @@ cite, code, tt {
|
||||
letter-spacing: -0.02em;
|
||||
}
|
||||
|
||||
table.deprecated code.literal {
|
||||
word-break: break-all;
|
||||
}
|
||||
|
||||
tt {
|
||||
background-color: #f2f2f2;
|
||||
border: 1px solid #ddd;
|
||||
border-radius: 2px;
|
||||
color: #333;
|
||||
padding: 1px;
|
||||
padding: 1px 0.2em;
|
||||
}
|
||||
|
||||
tt.descname, tt.descclassname, tt.xref {
|
||||
|
||||
+29
-4
@@ -3,6 +3,7 @@
|
||||
# Sphinx documentation build configuration file
|
||||
|
||||
import re
|
||||
|
||||
import sphinx
|
||||
|
||||
|
||||
@@ -15,7 +16,7 @@ templates_path = ['_templates']
|
||||
exclude_patterns = ['_build']
|
||||
|
||||
project = 'Sphinx'
|
||||
copyright = '2007-2017, Georg Brandl and the Sphinx team'
|
||||
copyright = '2007-2018, Georg Brandl and the Sphinx team'
|
||||
version = sphinx.__display_version__
|
||||
release = version
|
||||
show_authors = True
|
||||
@@ -38,11 +39,12 @@ epub_uid = 'web-site'
|
||||
epub_scheme = 'url'
|
||||
epub_identifier = epub_publisher
|
||||
epub_pre_files = [('index.xhtml', 'Welcome')]
|
||||
epub_post_files = [('install.xhtml', 'Installing Sphinx'),
|
||||
epub_post_files = [('usage/installation.xhtml', 'Installing Sphinx'),
|
||||
('develop.xhtml', 'Sphinx development')]
|
||||
epub_exclude_files = ['_static/opensearch.xml', '_static/doctools.js',
|
||||
'_static/jquery.js', '_static/searchtools.js',
|
||||
'_static/underscore.js', '_static/basic.css',
|
||||
'_static/language_data.js',
|
||||
'search.html', '_static/websupport.js']
|
||||
epub_fix_images = False
|
||||
epub_max_image_width = 0
|
||||
@@ -55,8 +57,21 @@ latex_documents = [('contents', 'sphinx.tex', 'Sphinx Documentation',
|
||||
'Georg Brandl', 'manual', 1)]
|
||||
latex_logo = '_static/sphinx.png'
|
||||
latex_elements = {
|
||||
'fontpkg': '\\usepackage{palatino}',
|
||||
'fontenc': r'\usepackage[LGR,X2,T1]{fontenc}',
|
||||
'fontpkg': r'''
|
||||
\usepackage[sc]{mathpazo}
|
||||
\usepackage[scaled]{helvet}
|
||||
\usepackage{courier}
|
||||
\substitutefont{LGR}{\rmdefault}{cmr}
|
||||
\substitutefont{LGR}{\sfdefault}{cmss}
|
||||
\substitutefont{LGR}{\ttdefault}{cmtt}
|
||||
\substitutefont{X2}{\rmdefault}{cmr}
|
||||
\substitutefont{X2}{\sfdefault}{cmss}
|
||||
\substitutefont{X2}{\ttdefault}{cmtt}
|
||||
''',
|
||||
'passoptionstopackages': '\\PassOptionsToPackage{svgnames}{xcolor}',
|
||||
'preamble': '\\DeclareUnicodeCharacter{229E}{\\ensuremath{\\boxplus}}',
|
||||
'fvset': '\\fvset{fontsize=auto}',
|
||||
# fix missing index entry due to RTD doing only once pdflatex after makeindex
|
||||
'printindex': r'''
|
||||
\IfFileExists{\jobname.ind}
|
||||
@@ -65,6 +80,7 @@ latex_elements = {
|
||||
''',
|
||||
}
|
||||
latex_show_urls = 'footnote'
|
||||
latex_use_xindy = True
|
||||
|
||||
autodoc_member_order = 'groupwise'
|
||||
todo_include_todos = True
|
||||
@@ -84,6 +100,8 @@ man_pages = [
|
||||
'template generator', '', 1),
|
||||
('man/sphinx-apidoc', 'sphinx-apidoc', 'Sphinx API doc generator tool',
|
||||
'', 1),
|
||||
('man/sphinx-autogen', 'sphinx-autogen', 'Generate autodoc stub pages',
|
||||
'', 1),
|
||||
]
|
||||
|
||||
texinfo_documents = [
|
||||
@@ -94,7 +112,7 @@ texinfo_documents = [
|
||||
|
||||
# We're not using intersphinx right now, but if we did, this would be part of
|
||||
# the mapping:
|
||||
intersphinx_mapping = {'python': ('https://docs.python.org/2/', None)}
|
||||
intersphinx_mapping = {'python': ('https://docs.python.org/3/', None)}
|
||||
|
||||
# Sphinx document translation with sphinx gettext feature uses these settings:
|
||||
locale_dirs = ['locale/']
|
||||
@@ -134,3 +152,10 @@ def setup(app):
|
||||
names=['param'], can_collapse=True)
|
||||
app.add_object_type('event', 'event', 'pair: %s; event', parse_event,
|
||||
doc_field_types=[fdesc])
|
||||
|
||||
# workaround for RTD
|
||||
from sphinx.util import logging
|
||||
logger = logging.getLogger(__name__)
|
||||
app.info = lambda *args, **kwargs: logger.info(*args, **kwargs)
|
||||
app.warn = lambda *args, **kwargs: logger.warning(*args, **kwargs)
|
||||
app.debug = lambda *args, **kwargs: logger.debug(*args, **kwargs)
|
||||
+14
-12
@@ -7,24 +7,25 @@ Sphinx documentation contents
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
usage/installation
|
||||
usage/quickstart
|
||||
usage/restructuredtext/index
|
||||
usage/markdown
|
||||
usage/configuration
|
||||
usage/builders/index
|
||||
usage/extensions/index
|
||||
usage/theming
|
||||
usage/advanced/intl
|
||||
usage/advanced/setuptools
|
||||
usage/advanced/websupport/index
|
||||
|
||||
intro
|
||||
tutorial
|
||||
invocation
|
||||
rest
|
||||
markup/index
|
||||
domains
|
||||
builders
|
||||
config
|
||||
intl
|
||||
man/index
|
||||
theming
|
||||
setuptools
|
||||
templating
|
||||
latex
|
||||
markdown
|
||||
extensions
|
||||
extdev/index
|
||||
extdev/tutorials/index
|
||||
websupport
|
||||
|
||||
faq
|
||||
glossary
|
||||
@@ -34,6 +35,7 @@ Sphinx documentation contents
|
||||
authors
|
||||
|
||||
|
||||
|
||||
Indices and tables
|
||||
==================
|
||||
|
||||
|
||||
+17
-17
@@ -12,7 +12,7 @@ Sphinx is a maintained by a group of volunteers. We value every contribution!
|
||||
* The mailing list for development is at `Google Groups
|
||||
<https://groups.google.com/forum/#!forum/sphinx-dev>`_.
|
||||
* There is also the #sphinx-doc IRC channel on `freenode
|
||||
<http://freenode.net/>`_.
|
||||
<https://freenode.net/>`_.
|
||||
|
||||
For more about our development process and methods, see the :doc:`devguide`.
|
||||
|
||||
@@ -106,40 +106,40 @@ own extensions.
|
||||
|
||||
.. _aafigure: https://launchpad.net/aafigure
|
||||
.. _gnuplot: http://www.gnuplot.info/
|
||||
.. _paver: http://paver.github.io/paver/
|
||||
.. _Sword: http://www.crosswire.org/sword/
|
||||
.. _paver: https://paver.readthedocs.io/en/latest/
|
||||
.. _Sword: https://www.crosswire.org/sword/
|
||||
.. _Lilypond: http://lilypond.org/
|
||||
.. _sdedit: http://sdedit.sourceforge.net/
|
||||
.. _Trac: http://trac.edgewall.org
|
||||
.. _TracLinks: http://trac.edgewall.org/wiki/TracLinks
|
||||
.. _OmegaT: http://www.omegat.org/
|
||||
.. _Trac: https://trac.edgewall.org/
|
||||
.. _TracLinks: https://trac.edgewall.org/wiki/TracLinks
|
||||
.. _OmegaT: https://omegat.org/
|
||||
.. _PlantUML: http://plantuml.com/
|
||||
.. _PyEnchant: http://www.rfk.id.au/software/pyenchant/
|
||||
.. _PyEnchant: https://pythonhosted.org/pyenchant/
|
||||
.. _sadisplay: https://bitbucket.org/estin/sadisplay/wiki/Home
|
||||
.. _blockdiag: http://blockdiag.com/en/
|
||||
.. _seqdiag: http://blockdiag.com/en/
|
||||
.. _actdiag: http://blockdiag.com/en/
|
||||
.. _nwdiag: http://blockdiag.com/en/
|
||||
.. _Google Analytics: http://www.google.com/analytics/
|
||||
.. _Google Analytics: https://www.google.com/analytics/
|
||||
.. _Google Chart: https://developers.google.com/chart/
|
||||
.. _Google Maps: https://www.google.com/maps
|
||||
.. _Google style: https://google.github.io/styleguide/pyguide.html
|
||||
.. _NumPy style: https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt
|
||||
.. _hyphenator: https://github.com/mnater/hyphenator
|
||||
.. _exceltable: http://pythonhosted.org/sphinxcontrib-exceltable/
|
||||
.. _YouTube: http://www.youtube.com/
|
||||
.. _ClearQuest: http://www-03.ibm.com/software/products/en/clearquest
|
||||
.. _Zope interfaces: http://docs.zope.org/zope.interface/README.html
|
||||
.. _slideshare: http://www.slideshare.net/
|
||||
.. _exceltable: https://pythonhosted.org/sphinxcontrib-exceltable/
|
||||
.. _YouTube: https://www.youtube.com/
|
||||
.. _ClearQuest: https://www.ibm.com/us-en/marketplace/rational-clearquest
|
||||
.. _Zope interfaces: https://zopeinterface.readthedocs.io/en/latest/README.html
|
||||
.. _slideshare: https://www.slideshare.net/
|
||||
.. _TikZ/PGF LaTeX package: https://sourceforge.net/projects/pgf/
|
||||
.. _MATLAB: http://www.mathworks.com/products/matlab/
|
||||
.. _MATLAB: https://www.mathworks.com/products/matlab.html
|
||||
.. _swf: https://bitbucket.org/klorenz/sphinxcontrib-swf
|
||||
.. _findanything: https://bitbucket.org/klorenz/sphinxcontrib-findanything
|
||||
.. _cmakedomain: https://bitbucket.org/klorenz/sphinxcontrib-cmakedomain
|
||||
.. _GNU Make: http://www.gnu.org/software/make/
|
||||
.. _GNU Make: https://www.gnu.org/software/make/
|
||||
.. _makedomain: https://bitbucket.org/klorenz/sphinxcontrib-makedomain
|
||||
.. _inlinesyntaxhighlight: http://sphinxcontrib-inlinesyntaxhighlight.readthedocs.org
|
||||
.. _inlinesyntaxhighlight: https://sphinxcontrib-inlinesyntaxhighlight.readthedocs.io/
|
||||
.. _CMake: https://cmake.org
|
||||
.. _domaintools: https://bitbucket.org/klorenz/sphinxcontrib-domaintools
|
||||
.. _restbuilder: https://pypi.python.org/pypi/sphinxcontrib-restbuilder
|
||||
.. _restbuilder: https://pypi.org/project/sphinxcontrib-restbuilder/
|
||||
.. _Lasso: http://www.lassosoft.com/
|
||||
@@ -1,25 +0,0 @@
|
||||
Builtin Sphinx extensions
|
||||
-------------------------
|
||||
|
||||
These extensions are built in and can be activated by respective entries in the
|
||||
:confval:`extensions` configuration value:
|
||||
|
||||
.. toctree::
|
||||
|
||||
autodoc
|
||||
autosectionlabel
|
||||
autosummary
|
||||
coverage
|
||||
doctest
|
||||
extlinks
|
||||
githubpages
|
||||
graphviz
|
||||
ifconfig
|
||||
imgconverter
|
||||
inheritance
|
||||
intersphinx
|
||||
linkcode
|
||||
math
|
||||
napoleon
|
||||
todo
|
||||
viewcode
|
||||
@@ -1,35 +0,0 @@
|
||||
Third-party extensions
|
||||
----------------------
|
||||
|
||||
You can find several extensions contributed by users in the `Sphinx Contrib`_
|
||||
repository. It is open for anyone who wants to maintain an extension
|
||||
publicly; just send a short message asking for write permissions.
|
||||
|
||||
There are also several extensions hosted elsewhere. The `Sphinx extension
|
||||
survey <http://sphinxext-survey.readthedocs.org/en/latest/>`__ contains a
|
||||
comprehensive list.
|
||||
|
||||
If you write an extension that you think others will find useful or you think
|
||||
should be included as a part of Sphinx, please write to the project mailing
|
||||
list (`join here <https://groups.google.com/forum/#!forum/sphinx-dev>`_).
|
||||
|
||||
.. _Sphinx Contrib: https://bitbucket.org/birkenfeld/sphinx-contrib
|
||||
|
||||
|
||||
Where to put your own extensions?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Extensions local to a project should be put within the project's directory
|
||||
structure. Set Python's module search path, ``sys.path``, accordingly so that
|
||||
Sphinx can find them.
|
||||
E.g., if your extension ``foo.py`` lies in the ``exts`` subdirectory of the
|
||||
project root, put into :file:`conf.py`::
|
||||
|
||||
import sys, os
|
||||
|
||||
sys.path.append(os.path.abspath('exts'))
|
||||
|
||||
extensions = ['foo']
|
||||
|
||||
You can also install extensions anywhere else on ``sys.path``, e.g. in the
|
||||
``site-packages`` directory.
|
||||
@@ -1,64 +0,0 @@
|
||||
:mod:`sphinx.ext.viewcode` -- Add links to highlighted source code
|
||||
==================================================================
|
||||
|
||||
.. module:: sphinx.ext.viewcode
|
||||
:synopsis: Add links to a highlighted version of the source code.
|
||||
.. moduleauthor:: Georg Brandl
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
|
||||
This extension looks at your Python object descriptions (``.. class::``,
|
||||
``.. function::`` etc.) and tries to find the source files where the objects are
|
||||
contained. When found, a separate HTML page will be output for each module with
|
||||
a highlighted version of the source code, and a link will be added to all object
|
||||
descriptions that leads to the source code of the described object. A link back
|
||||
from the source to the description will also be inserted.
|
||||
|
||||
This extension works only on HTML related builders like ``html``,
|
||||
``applehelp``, ``devhelp``, ``htmlhelp``, ``qthelp`` and so on except
|
||||
``singlehtml``. By default ``epub`` builder doesn't
|
||||
support this extension (see :confval:`viewcode_enable_epub`).
|
||||
|
||||
There is an additional config value:
|
||||
|
||||
.. confval:: viewcode_import
|
||||
|
||||
If this is ``True``, viewcode extension will follow alias objects that
|
||||
imported from another module such as functions, classes and attributes.
|
||||
As side effects, this option
|
||||
else they produce nothing. The default is ``True``.
|
||||
|
||||
.. warning::
|
||||
|
||||
:confval:`viewcode_import` **imports** the modules to be followed real
|
||||
location. If any modules have side effects on import, these will be
|
||||
executed by ``viewcode`` when ``sphinx-build`` is run.
|
||||
|
||||
If you document scripts (as opposed to library modules), make sure their
|
||||
main routine is protected by a ``if __name__ == '__main__'`` condition.
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
.. confval:: viewcode_enable_epub
|
||||
|
||||
If this is ``True``, viewcode extension is also enabled even if you use
|
||||
epub builders. This extension generates pages outside toctree, but this
|
||||
is not preferred as epub format.
|
||||
|
||||
Until 1.4.x, this extension is always enabled. If you want to generate
|
||||
epub as same as 1.4.x, you should set ``True``, but epub format checker's
|
||||
score becomes worse.
|
||||
|
||||
The default is ``False``.
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
.. warning::
|
||||
|
||||
Not all epub readers support pages generated by viewcode extension.
|
||||
These readers ignore links to pages are not under toctree.
|
||||
|
||||
Some reader's rendering result are corrupted and
|
||||
`epubcheck <https://github.com/IDPF/epubcheck>`_'s score
|
||||
becomes worse even if the reader supports.
|
||||
+76
-422
@@ -7,9 +7,9 @@ Application API
|
||||
:synopsis: Application class and extensibility interface.
|
||||
|
||||
|
||||
Each Sphinx extension is a Python module with at least a :func:`setup` function.
|
||||
This function is called at initialization time with one argument, the
|
||||
application object representing the Sphinx process.
|
||||
Each Sphinx extension is a Python module with at least a :func:`setup`
|
||||
function. This function is called at initialization time with one argument,
|
||||
the application object representing the Sphinx process.
|
||||
|
||||
.. class:: Sphinx
|
||||
|
||||
@@ -23,387 +23,81 @@ These methods are usually called in an extension's ``setup()`` function.
|
||||
Examples of using the Sphinx extension API can be seen in the :mod:`sphinx.ext`
|
||||
package.
|
||||
|
||||
.. method:: Sphinx.setup_extension(name)
|
||||
.. currentmodule:: sphinx.application
|
||||
|
||||
Load the extension given by the module *name*. Use this if your extension
|
||||
needs the features provided by another extension.
|
||||
.. automethod:: Sphinx.setup_extension(name)
|
||||
|
||||
.. method:: Sphinx.add_builder(builder)
|
||||
.. automethod:: Sphinx.require_sphinx(version)
|
||||
|
||||
Register a new builder. *builder* must be a class that inherits from
|
||||
:class:`~sphinx.builders.Builder`.
|
||||
.. automethod:: Sphinx.connect(event, callback)
|
||||
|
||||
.. method:: Sphinx.add_config_value(name, default, rebuild)
|
||||
.. automethod:: Sphinx.disconnect(listener_id)
|
||||
|
||||
Register a configuration value. This is necessary for Sphinx to recognize
|
||||
new values and set default values accordingly. The *name* should be prefixed
|
||||
with the extension name, to avoid clashes. The *default* value can be any
|
||||
Python object. The string value *rebuild* must be one of those values:
|
||||
.. automethod:: Sphinx.add_builder(builder)
|
||||
|
||||
* ``'env'`` if a change in the setting only takes effect when a document is
|
||||
parsed -- this means that the whole environment must be rebuilt.
|
||||
* ``'html'`` if a change in the setting needs a full rebuild of HTML
|
||||
documents.
|
||||
* ``''`` if a change in the setting will not need any special rebuild.
|
||||
.. automethod:: Sphinx.add_config_value(name, default, rebuild)
|
||||
|
||||
.. versionchanged:: 0.4
|
||||
If the *default* value is a callable, it will be called with the config
|
||||
object as its argument in order to get the default value. This can be
|
||||
used to implement config values whose default depends on other values.
|
||||
.. automethod:: Sphinx.add_event(name)
|
||||
|
||||
.. versionchanged:: 0.6
|
||||
Changed *rebuild* from a simple boolean (equivalent to ``''`` or
|
||||
``'env'``) to a string. However, booleans are still accepted and
|
||||
converted internally.
|
||||
.. automethod:: Sphinx.set_translator(name, translator_class)
|
||||
|
||||
.. method:: Sphinx.add_domain(domain)
|
||||
.. automethod:: Sphinx.add_node(node, \*\*kwds)
|
||||
|
||||
Make the given *domain* (which must be a class; more precisely, a subclass of
|
||||
:class:`~sphinx.domains.Domain`) known to Sphinx.
|
||||
.. automethod:: Sphinx.add_enumerable_node(node, figtype, title_getter=None, \*\*kwds)
|
||||
|
||||
.. versionadded:: 1.0
|
||||
.. method:: Sphinx.add_directive(name, func, content, arguments, \*\*options)
|
||||
.. automethod:: Sphinx.add_directive(name, directiveclass)
|
||||
|
||||
.. method:: Sphinx.override_domain(domain)
|
||||
.. automethod:: Sphinx.add_role(name, role)
|
||||
|
||||
Make the given *domain* class known to Sphinx, assuming that there is already
|
||||
a domain with its ``.name``. The new domain must be a subclass of the
|
||||
existing one.
|
||||
.. automethod:: Sphinx.add_generic_role(name, nodeclass)
|
||||
|
||||
.. versionadded:: 1.0
|
||||
.. automethod:: Sphinx.add_domain(domain)
|
||||
|
||||
.. method:: Sphinx.add_index_to_domain(domain, index)
|
||||
.. automethod:: Sphinx.override_domain(domain)
|
||||
|
||||
Add a custom *index* class to the domain named *domain*. *index* must be a
|
||||
subclass of :class:`~sphinx.domains.Index`.
|
||||
.. method:: Sphinx.add_directive_to_domain(domain, name, func, content, arguments, \*\*options)
|
||||
.. automethod:: Sphinx.add_directive_to_domain(domain, name, directiveclass)
|
||||
|
||||
.. versionadded:: 1.0
|
||||
.. automethod:: Sphinx.add_role_to_domain(domain, name, role)
|
||||
|
||||
.. method:: Sphinx.add_event(name)
|
||||
.. automethod:: Sphinx.add_index_to_domain(domain, index)
|
||||
|
||||
Register an event called *name*. This is needed to be able to emit it.
|
||||
.. automethod:: Sphinx.add_object_type(directivename, rolename, indextemplate='', parse_node=None, ref_nodeclass=None, objname='', doc_field_types=[])
|
||||
|
||||
.. method:: Sphinx.set_translator(name, translator_class)
|
||||
.. automethod:: Sphinx.add_crossref_type(directivename, rolename, indextemplate='', ref_nodeclass=None, objname='')
|
||||
|
||||
Register or override a Docutils translator class. This is used to register
|
||||
a custom output translator or to replace a builtin translator.
|
||||
This allows extensions to use custom translator and define custom
|
||||
nodes for the translator (see :meth:`add_node`).
|
||||
.. automethod:: Sphinx.add_transform(transform)
|
||||
|
||||
.. versionadded:: 1.3
|
||||
.. automethod:: Sphinx.add_post_transform(transform)
|
||||
|
||||
.. method:: Sphinx.add_node(node, **kwds)
|
||||
.. automethod:: Sphinx.add_js_file(filename, **kwargs)
|
||||
|
||||
Register a Docutils node class. This is necessary for Docutils internals.
|
||||
It may also be used in the future to validate nodes in the parsed documents.
|
||||
.. automethod:: Sphinx.add_css_file(filename, **kwargs)
|
||||
|
||||
Node visitor functions for the Sphinx HTML, LaTeX, text and manpage writers
|
||||
can be given as keyword arguments: the keyword should be one or more of
|
||||
``'html'``, ``'latex'``, ``'text'``, ``'man'``, ``'texinfo'`` or any other
|
||||
supported translators, the value a 2-tuple of ``(visit, depart)`` methods.
|
||||
``depart`` can be ``None`` if the ``visit`` function raises
|
||||
:exc:`docutils.nodes.SkipNode`. Example:
|
||||
.. automethod:: Sphinx.add_latex_package(packagename, options=None)
|
||||
|
||||
.. code-block:: python
|
||||
.. automethod:: Sphinx.add_lexer(alias, lexer)
|
||||
|
||||
class math(docutils.nodes.Element): pass
|
||||
.. automethod:: Sphinx.add_autodocumenter(cls)
|
||||
|
||||
def visit_math_html(self, node):
|
||||
self.body.append(self.starttag(node, 'math'))
|
||||
def depart_math_html(self, node):
|
||||
self.body.append('</math>')
|
||||
.. automethod:: Sphinx.add_autodoc_attrgetter(type, getter)
|
||||
|
||||
app.add_node(math, html=(visit_math_html, depart_math_html))
|
||||
.. automethod:: Sphinx.add_search_language(cls)
|
||||
|
||||
Obviously, translators for which you don't specify visitor methods will choke
|
||||
on the node when encountered in a document to translate.
|
||||
.. automethod:: Sphinx.add_source_suffix(suffix, filetype)
|
||||
|
||||
.. versionchanged:: 0.5
|
||||
Added the support for keyword arguments giving visit functions.
|
||||
.. automethod:: Sphinx.add_source_parser(parser)
|
||||
|
||||
.. method:: Sphinx.add_enumerable_node(node, figtype, title_getter=None, **kwds)
|
||||
.. automethod:: Sphinx.add_env_collector(collector)
|
||||
|
||||
Register a Docutils node class as a numfig target. Sphinx numbers the node
|
||||
automatically. And then the users can refer it using :rst:role:`numref`.
|
||||
.. automethod:: Sphinx.add_html_theme(name, theme_path)
|
||||
|
||||
*figtype* is a type of enumerable nodes. Each figtypes have individual
|
||||
numbering sequences. As a system figtypes, ``figure``, ``table`` and
|
||||
``code-block`` are defined. It is able to add custom nodes to these
|
||||
default figtypes. It is also able to define new custom figtype if new
|
||||
figtype is given.
|
||||
.. automethod:: Sphinx.add_html_math_renderer(name, inline_renderers, block_renderers)
|
||||
|
||||
*title_getter* is a getter function to obtain the title of node. It takes
|
||||
an instance of the enumerable node, and it must return its title as string.
|
||||
The title is used to the default title of references for :rst:role:`ref`.
|
||||
By default, Sphinx searches ``docutils.nodes.caption`` or
|
||||
``docutils.nodes.title`` from the node as a title.
|
||||
|
||||
Other keyword arguments are used for node visitor functions. See the
|
||||
:meth:`Sphinx.add_node` for details.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
.. method:: Sphinx.add_directive(name, func, content, arguments, **options)
|
||||
Sphinx.add_directive(name, directiveclass)
|
||||
|
||||
Register a Docutils directive. *name* must be the prospective directive
|
||||
name. There are two possible ways to write a directive:
|
||||
|
||||
* In the docutils 0.4 style, *obj* is the directive function. *content*,
|
||||
*arguments* and *options* are set as attributes on the function and
|
||||
determine whether the directive has content, arguments and options,
|
||||
respectively. **This style is deprecated.**
|
||||
|
||||
* In the docutils 0.5 style, *directiveclass* is the directive class. It
|
||||
must already have attributes named *has_content*, *required_arguments*,
|
||||
*optional_arguments*, *final_argument_whitespace* and *option_spec* that
|
||||
correspond to the options for the function way. See `the Docutils docs
|
||||
<http://docutils.sourceforge.net/docs/howto/rst-directives.html>`_ for
|
||||
details.
|
||||
|
||||
The directive class must inherit from the class
|
||||
``docutils.parsers.rst.Directive``.
|
||||
|
||||
For example, the (already existing) :rst:dir:`literalinclude` directive would
|
||||
be added like this:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
from docutils.parsers.rst import directives
|
||||
add_directive('literalinclude', literalinclude_directive,
|
||||
content = 0, arguments = (1, 0, 0),
|
||||
linenos = directives.flag,
|
||||
language = directives.unchanged,
|
||||
encoding = directives.encoding)
|
||||
|
||||
.. versionchanged:: 0.6
|
||||
Docutils 0.5-style directive classes are now supported.
|
||||
|
||||
.. method:: Sphinx.add_directive_to_domain(domain, name, func, content, arguments, **options)
|
||||
Sphinx.add_directive_to_domain(domain, name, directiveclass)
|
||||
|
||||
Like :meth:`add_directive`, but the directive is added to the domain named
|
||||
*domain*.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
.. method:: Sphinx.add_role(name, role)
|
||||
|
||||
Register a Docutils role. *name* must be the role name that occurs in the
|
||||
source, *role* the role function (see the `Docutils documentation
|
||||
<http://docutils.sourceforge.net/docs/howto/rst-roles.html>`_ on details).
|
||||
|
||||
.. method:: Sphinx.add_role_to_domain(domain, name, role)
|
||||
|
||||
Like :meth:`add_role`, but the role is added to the domain named *domain*.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
.. method:: Sphinx.add_generic_role(name, nodeclass)
|
||||
|
||||
Register a Docutils role that does nothing but wrap its contents in the
|
||||
node given by *nodeclass*.
|
||||
|
||||
.. versionadded:: 0.6
|
||||
|
||||
.. method:: Sphinx.add_object_type(directivename, rolename, indextemplate='', parse_node=None, \
|
||||
ref_nodeclass=None, objname='', doc_field_types=[])
|
||||
|
||||
This method is a very convenient way to add a new :term:`object` type that
|
||||
can be cross-referenced. It will do this:
|
||||
|
||||
* Create a new directive (called *directivename*) for documenting an object.
|
||||
It will automatically add index entries if *indextemplate* is nonempty; if
|
||||
given, it must contain exactly one instance of ``%s``. See the example
|
||||
below for how the template will be interpreted.
|
||||
* Create a new role (called *rolename*) to cross-reference to these
|
||||
object descriptions.
|
||||
* If you provide *parse_node*, it must be a function that takes a string and
|
||||
a docutils node, and it must populate the node with children parsed from
|
||||
the string. It must then return the name of the item to be used in
|
||||
cross-referencing and index entries. See the :file:`conf.py` file in the
|
||||
source for this documentation for an example.
|
||||
* The *objname* (if not given, will default to *directivename*) names the
|
||||
type of object. It is used when listing objects, e.g. in search results.
|
||||
|
||||
For example, if you have this call in a custom Sphinx extension::
|
||||
|
||||
app.add_object_type('directive', 'dir', 'pair: %s; directive')
|
||||
|
||||
you can use this markup in your documents::
|
||||
|
||||
.. rst:directive:: function
|
||||
|
||||
Document a function.
|
||||
|
||||
<...>
|
||||
|
||||
See also the :rst:dir:`function` directive.
|
||||
|
||||
For the directive, an index entry will be generated as if you had prepended ::
|
||||
|
||||
.. index:: pair: function; directive
|
||||
|
||||
The reference node will be of class ``literal`` (so it will be rendered in a
|
||||
proportional font, as appropriate for code) unless you give the
|
||||
*ref_nodeclass* argument, which must be a docutils node class. Most useful
|
||||
are ``docutils.nodes.emphasis`` or ``docutils.nodes.strong`` -- you can also
|
||||
use ``docutils.nodes.generated`` if you want no further text decoration. If
|
||||
the text should be treated as literal (e.g. no smart quote replacement), but
|
||||
not have typewriter styling, use ``sphinx.addnodes.literal_emphasis`` or
|
||||
``sphinx.addnodes.literal_strong``.
|
||||
|
||||
For the role content, you have the same syntactical possibilities as for
|
||||
standard Sphinx roles (see :ref:`xref-syntax`).
|
||||
|
||||
This method is also available under the deprecated alias
|
||||
``add_description_unit``.
|
||||
|
||||
.. method:: Sphinx.add_crossref_type(directivename, rolename, indextemplate='', ref_nodeclass=None, objname='')
|
||||
|
||||
This method is very similar to :meth:`add_object_type` except that the
|
||||
directive it generates must be empty, and will produce no output.
|
||||
|
||||
That means that you can add semantic targets to your sources, and refer to
|
||||
them using custom roles instead of generic ones (like :rst:role:`ref`).
|
||||
Example call::
|
||||
|
||||
app.add_crossref_type('topic', 'topic', 'single: %s', docutils.nodes.emphasis)
|
||||
|
||||
Example usage::
|
||||
|
||||
.. topic:: application API
|
||||
|
||||
The application API
|
||||
-------------------
|
||||
|
||||
<...>
|
||||
|
||||
See also :topic:`this section <application API>`.
|
||||
|
||||
(Of course, the element following the ``topic`` directive needn't be a
|
||||
section.)
|
||||
|
||||
.. method:: Sphinx.add_transform(transform)
|
||||
|
||||
Add the standard docutils :class:`Transform` subclass *transform* to the list
|
||||
of transforms that are applied after Sphinx parses a reST document.
|
||||
|
||||
.. method:: Sphinx.add_post_transform(transform)
|
||||
|
||||
Add the standard docutils :class:`Transform` subclass *transform* to the list
|
||||
of transforms that are applied before Sphinx writes a document.
|
||||
|
||||
.. method:: Sphinx.add_javascript(filename)
|
||||
|
||||
Add *filename* to the list of JavaScript files that the default HTML template
|
||||
will include. The filename must be relative to the HTML static path, see
|
||||
:confval:`the docs for the config value <html_static_path>`. A full URI with
|
||||
scheme, like ``http://example.org/foo.js``, is also supported.
|
||||
|
||||
.. versionadded:: 0.5
|
||||
|
||||
.. method:: Sphinx.add_stylesheet(filename, alternate=None, title=None)
|
||||
|
||||
Add *filename* to the list of CSS files that the default HTML template will
|
||||
include. Like for :meth:`add_javascript`, the filename must be relative to
|
||||
the HTML static path, or a full URI with scheme.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
Optional ``alternate`` and/or ``title`` attributes can be supplied with
|
||||
the *alternate* (of boolean type) and *title* (a string) arguments. The
|
||||
default is no title and *alternate* = ``False`` (see `this explanation
|
||||
<https://developer.mozilla.org/en-US/docs/Web/CSS/Alternative_style_sheets>`_).
|
||||
|
||||
.. method:: Sphinx.add_latex_package(packagename, options=None)
|
||||
|
||||
Add *packagename* to the list of packages that LaTeX source code will include.
|
||||
If you provide *options*, it will be taken to `\usepackage` declaration.
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
app.add_latex_package('mypackage') # => \usepackage{mypackage}
|
||||
app.add_latex_package('mypackage', 'foo,bar') # => \usepackage[foo,bar]{mypackage}
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
.. method:: Sphinx.add_lexer(alias, lexer)
|
||||
|
||||
Use *lexer*, which must be an instance of a Pygments lexer class, to
|
||||
highlight code blocks with the given language *alias*.
|
||||
|
||||
.. versionadded:: 0.6
|
||||
|
||||
.. method:: Sphinx.add_autodocumenter(cls)
|
||||
|
||||
Add *cls* as a new documenter class for the :mod:`sphinx.ext.autodoc`
|
||||
extension. It must be a subclass of :class:`sphinx.ext.autodoc.Documenter`.
|
||||
This allows to auto-document new types of objects. See the source of the
|
||||
autodoc module for examples on how to subclass :class:`Documenter`.
|
||||
|
||||
.. XXX add real docs for Documenter and subclassing
|
||||
|
||||
.. versionadded:: 0.6
|
||||
|
||||
.. method:: Sphinx.add_autodoc_attrgetter(type, getter)
|
||||
|
||||
Add *getter*, which must be a function with an interface compatible to the
|
||||
:func:`getattr` builtin, as the autodoc attribute getter for objects that are
|
||||
instances of *type*. All cases where autodoc needs to get an attribute of a
|
||||
type are then handled by this function instead of :func:`getattr`.
|
||||
|
||||
.. versionadded:: 0.6
|
||||
|
||||
.. method:: Sphinx.add_search_language(cls)
|
||||
|
||||
Add *cls*, which must be a subclass of :class:`sphinx.search.SearchLanguage`,
|
||||
as a support language for building the HTML full-text search index. The
|
||||
class must have a *lang* attribute that indicates the language it should be
|
||||
used for. See :confval:`html_search_language`.
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
.. method:: Sphinx.add_source_parser(suffix, parser)
|
||||
|
||||
Register a parser class for specified *suffix*.
|
||||
|
||||
.. versionadded:: 1.4
|
||||
|
||||
.. method:: Sphinx.add_html_theme(name, theme_path)
|
||||
|
||||
Register a HTML Theme. The *name* is a name of theme, and *path* is a
|
||||
full path to the theme (refs: :ref:`distribute-your-theme`).
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
.. method:: Sphinx.add_env_collector(collector)
|
||||
|
||||
Register an environment collector class (refs: :ref:`collector-api`)
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
.. method:: Sphinx.require_sphinx(version)
|
||||
|
||||
Compare *version* (which must be a ``major.minor`` version string,
|
||||
e.g. ``'1.1'``) with the version of the running Sphinx, and abort the build
|
||||
when it is too old.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
.. method:: Sphinx.connect(event, callback)
|
||||
|
||||
Register *callback* to be called when *event* is emitted. For details on
|
||||
available core events and the arguments of callback functions, please see
|
||||
:ref:`events`.
|
||||
|
||||
The method returns a "listener ID" that can be used as an argument to
|
||||
:meth:`disconnect`.
|
||||
|
||||
.. method:: Sphinx.disconnect(listener_id)
|
||||
|
||||
Unregister callback *listener_id*.
|
||||
.. automethod:: Sphinx.add_message_catalog(catalog, locale_dir)
|
||||
|
||||
.. automethod:: Sphinx.is_parallel_allowed(typ)
|
||||
|
||||
.. exception:: ExtensionError
|
||||
|
||||
@@ -414,44 +108,37 @@ package.
|
||||
Emitting events
|
||||
---------------
|
||||
|
||||
.. method:: Sphinx.emit(event, *arguments)
|
||||
.. class:: Sphinx
|
||||
|
||||
Emit *event* and pass *arguments* to the callback functions. Return the
|
||||
return values of all callbacks as a list. Do not emit core Sphinx events
|
||||
in extensions!
|
||||
.. automethod:: emit(event, \*arguments)
|
||||
|
||||
.. method:: Sphinx.emit_firstresult(event, *arguments)
|
||||
|
||||
Emit *event* and pass *arguments* to the callback functions. Return the
|
||||
result of the first callback that doesn't return ``None``.
|
||||
|
||||
.. versionadded:: 0.5
|
||||
.. automethod:: emit_firstresult(event, \*arguments)
|
||||
|
||||
|
||||
Producing messages / logging
|
||||
----------------------------
|
||||
Sphinx runtime information
|
||||
--------------------------
|
||||
|
||||
The application object also provides support for emitting leveled messages.
|
||||
The application object also provides runtime information as attributes.
|
||||
|
||||
.. note::
|
||||
.. attribute:: Sphinx.project
|
||||
|
||||
There is no "error" call: in Sphinx, errors are defined as things that stop
|
||||
the build; just raise an exception (:exc:`sphinx.errors.SphinxError` or a
|
||||
custom subclass) to do that.
|
||||
Target project. See :class:`.Project`.
|
||||
|
||||
.. deprecated:: 1.6
|
||||
.. attribute:: Sphinx.srcdir
|
||||
|
||||
Please use :ref:`logging-api` instead.
|
||||
Source directory.
|
||||
|
||||
.. automethod:: Sphinx.warn
|
||||
.. attribute:: Sphinx.confdir
|
||||
|
||||
.. automethod:: Sphinx.info
|
||||
Directory containing ``conf.py``.
|
||||
|
||||
.. automethod:: Sphinx.verbose
|
||||
.. attribute:: Sphinx.doctreedir
|
||||
|
||||
.. automethod:: Sphinx.debug
|
||||
Directory for storing pickled doctrees.
|
||||
|
||||
.. automethod:: Sphinx.debug2
|
||||
.. attribute:: Sphinx.outdir
|
||||
|
||||
Directory for storing built document.
|
||||
|
||||
|
||||
.. _events:
|
||||
@@ -478,6 +165,12 @@ handlers to the events. Example:
|
||||
Emitted when the builder object has been created. It is available as
|
||||
``app.builder``.
|
||||
|
||||
.. event:: config-inited (app, config)
|
||||
|
||||
Emitted when the config object has been initialized.
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
.. event:: env-get-outdated (app, env, added, changed, removed)
|
||||
|
||||
Emitted when the environment determines which source files have changed and
|
||||
@@ -556,7 +249,7 @@ handlers to the events. Example:
|
||||
Here is the place to replace custom nodes that don't have visitor methods in
|
||||
the writers, so that they don't cause errors when the writers encounter them.
|
||||
|
||||
.. event:: env-merge-info (env, docnames, other)
|
||||
.. event:: env-merge-info (app, env, docnames, other)
|
||||
|
||||
This event is only emitted when parallel reading of documents is enabled. It
|
||||
is emitted once for every subprocess that has read some documents.
|
||||
@@ -590,9 +283,9 @@ handlers to the events. Example:
|
||||
.. versionchanged:: 1.3
|
||||
The handlers' return value is now used.
|
||||
|
||||
.. event:: env-check-consistency (env)
|
||||
.. event:: env-check-consistency (app, env)
|
||||
|
||||
Emmited when Consistency checks phase. You can check consistency of
|
||||
Emitted when Consistency checks phase. You can check consistency of
|
||||
metadata for whole of documents.
|
||||
|
||||
.. versionadded:: 1.6
|
||||
@@ -652,28 +345,15 @@ Checking the Sphinx version
|
||||
|
||||
Use this to adapt your extension to API changes in Sphinx.
|
||||
|
||||
.. data:: version_info
|
||||
|
||||
A tuple of five elements; for Sphinx version 1.2.1 beta 3 this would be
|
||||
``(1, 2, 1, 'beta', 3)``.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
Before version 1.2, check the string ``sphinx.__version__``.
|
||||
.. autodata:: version_info
|
||||
|
||||
|
||||
The Config object
|
||||
-----------------
|
||||
|
||||
.. module:: sphinx.config
|
||||
.. currentmodule:: sphinx.config
|
||||
|
||||
.. class:: Config
|
||||
|
||||
The config object makes the values of all config values available as
|
||||
attributes.
|
||||
|
||||
It is available as the ``config`` attribute on the application and
|
||||
environment objects. For example, to get the value of :confval:`language`,
|
||||
use either ``app.config.language`` or ``env.config.language``.
|
||||
.. autoclass:: Config
|
||||
|
||||
|
||||
.. _template-bridge:
|
||||
@@ -694,38 +374,12 @@ Exceptions
|
||||
|
||||
.. module:: sphinx.errors
|
||||
|
||||
.. exception:: SphinxError
|
||||
.. autoexception:: SphinxError
|
||||
|
||||
This is the base class for "nice" exceptions. When such an exception is
|
||||
raised, Sphinx will abort the build and present the exception category and
|
||||
message to the user.
|
||||
.. autoexception:: ConfigError
|
||||
|
||||
Extensions are encouraged to derive from this exception for their custom
|
||||
errors.
|
||||
.. autoexception:: ExtensionError
|
||||
|
||||
Exceptions *not* derived from :exc:`SphinxError` are treated as unexpected
|
||||
and shown to the user with a part of the traceback (and the full traceback
|
||||
saved in a temporary file).
|
||||
.. autoexception:: ThemeError
|
||||
|
||||
.. attribute:: category
|
||||
|
||||
Description of the exception "category", used in converting the exception
|
||||
to a string ("category: message"). Should be set accordingly in
|
||||
subclasses.
|
||||
|
||||
.. exception:: ConfigError
|
||||
|
||||
Used for erroneous values or nonsensical combinations of configuration
|
||||
values.
|
||||
|
||||
.. exception:: ExtensionError
|
||||
|
||||
Used for errors in setting up extensions.
|
||||
|
||||
.. exception:: ThemeError
|
||||
|
||||
Used for errors to do with themes.
|
||||
|
||||
.. exception:: VersionRequirementError
|
||||
|
||||
Raised when the docs require a higher Sphinx version than the current one.
|
||||
.. autoexception:: VersionRequirementError
|
||||
@@ -15,7 +15,11 @@ Builder API
|
||||
|
||||
.. autoattribute:: name
|
||||
.. autoattribute:: format
|
||||
.. autoattribute:: epilog
|
||||
.. autoattribute:: supported_image_types
|
||||
.. autoattribute:: supported_remote_images
|
||||
.. autoattribute:: supported_data_uri_images
|
||||
.. autoattribute:: default_translator_class
|
||||
|
||||
These methods are predefined and will be called from the application:
|
||||
|
||||
|
||||
@@ -15,14 +15,14 @@ Build environment API
|
||||
|
||||
Reference to the :class:`.Config` object.
|
||||
|
||||
.. attribute:: project
|
||||
|
||||
Target project. See :class:`.Project`.
|
||||
|
||||
.. attribute:: srcdir
|
||||
|
||||
Source directory.
|
||||
|
||||
.. attribute:: confdir
|
||||
|
||||
Directory containing ``conf.py``.
|
||||
|
||||
.. attribute:: doctreedir
|
||||
|
||||
Directory for storing pickled doctrees.
|
||||
@@ -43,10 +43,6 @@ Build environment API
|
||||
|
||||
**Utility methods**
|
||||
|
||||
.. automethod:: warn
|
||||
|
||||
.. automethod:: warn_node
|
||||
|
||||
.. automethod:: doc2path
|
||||
|
||||
.. automethod:: relfn2path
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
.. _i18n-api:
|
||||
|
||||
i18n API
|
||||
========
|
||||
|
||||
.. currentmodule:: sphinx.locale
|
||||
|
||||
.. autofunction:: init
|
||||
|
||||
.. autofunction:: init_console
|
||||
|
||||
.. autofunction:: get_translation
|
||||
|
||||
.. autofunction:: _
|
||||
|
||||
.. autofunction:: __
|
||||
|
||||
@@ -52,6 +52,8 @@ Note that it is still necessary to register the builder using
|
||||
|
||||
.. _entry points: https://setuptools.readthedocs.io/en/latest/setuptools.html#dynamic-discovery-of-services-and-plugins
|
||||
|
||||
.. _ext-metadata:
|
||||
|
||||
Extension metadata
|
||||
------------------
|
||||
|
||||
@@ -63,6 +65,11 @@ as metadata of the extension. Metadata keys currently recognized are:
|
||||
* ``'version'``: a string that identifies the extension version. It is used for
|
||||
extension version requirement checking (see :confval:`needs_extensions`) and
|
||||
informational purposes. If not given, ``"unknown version"`` is substituted.
|
||||
* ``'env_version'``: an integer that identifies the version of env data
|
||||
structure if the extension stores any data to environment. It is used to
|
||||
detect the data structure has been changed from last build. The extensions
|
||||
have to increment the version when data structure has changed. If not given,
|
||||
Sphinx considers the extension does not stores any data to environment.
|
||||
* ``'parallel_read_safe'``: a boolean that specifies if parallel reading of
|
||||
source files can be used when the extension is loaded. It defaults to
|
||||
``False``, i.e. you have to explicitly specify your extension to be
|
||||
@@ -79,6 +86,7 @@ APIs used for writing extensions
|
||||
|
||||
tutorials/index
|
||||
appapi
|
||||
projectapi
|
||||
envapi
|
||||
builderapi
|
||||
collectorapi
|
||||
@@ -87,3 +95,597 @@ APIs used for writing extensions
|
||||
parserapi
|
||||
nodes
|
||||
logging
|
||||
i18n
|
||||
utils
|
||||
|
||||
Deprecated APIs
|
||||
---------------
|
||||
|
||||
On developing Sphinx, we are always careful to the compatibility of our APIs.
|
||||
But, sometimes, the change of interface are needed for some reasons. In such
|
||||
cases, we've marked them as deprecated. And they are kept during the two
|
||||
major versions (for more details, please see :ref:`deprecation-policy`).
|
||||
|
||||
The following is a list of deprecated interfaces.
|
||||
|
||||
.. tabularcolumns:: |>{\raggedright}\Y{.4}|>{\centering}\Y{.1}|>{\centering}\Y{.12}|>{\raggedright\arraybackslash}\Y{.38}|
|
||||
|
||||
.. |LaTeXHyphenate| raw:: latex
|
||||
|
||||
\hspace{0pt}
|
||||
|
||||
.. list-table:: deprecated APIs
|
||||
:header-rows: 1
|
||||
:class: deprecated
|
||||
:widths: 40, 10, 10, 40
|
||||
|
||||
* - Target
|
||||
- |LaTeXHyphenate|\ Deprecated
|
||||
- (will be) Removed
|
||||
- Alternatives
|
||||
|
||||
* - ``encoding`` argument of ``autodoc.Documenter.get_doc()``,
|
||||
``autodoc.DocstringSignatureMixin.get_doc()``,
|
||||
``autodoc.DocstringSignatureMixin._find_signature()``, and
|
||||
``autodoc.ClassDocumenter.get_doc()``
|
||||
- 2.0
|
||||
- 4.0
|
||||
- N/A
|
||||
|
||||
* - ``suffix`` argument of ``BuildEnvironment.doc2path()``
|
||||
- 2.0
|
||||
- 4.0
|
||||
- N/A
|
||||
|
||||
* - string style ``base`` argument of ``BuildEnvironment.doc2path()``
|
||||
- 2.0
|
||||
- 4.0
|
||||
- ``os.path.join()``
|
||||
|
||||
* - ``sphinx.ext.config.check_unicode()``
|
||||
- 2.0
|
||||
- 4.0
|
||||
- N/A
|
||||
|
||||
* - ``sphinx.ext.doctest.doctest_encode()``
|
||||
- 2.0
|
||||
- 4.0
|
||||
- N/A
|
||||
|
||||
* - ``sphinx.testing.util.remove_unicode_literal()``
|
||||
- 2.0
|
||||
- 4.0
|
||||
- N/A
|
||||
|
||||
* - ``sphinx.util.force_decode()``
|
||||
- 2.0
|
||||
- 4.0
|
||||
- N/A
|
||||
|
||||
* - ``sphinx.util.get_matching_docs()``
|
||||
- 2.0
|
||||
- 4.0
|
||||
- ``sphinx.util.get_matching_files()``
|
||||
|
||||
* - ``sphinx.util.osutil.walk()``
|
||||
- 2.0
|
||||
- 4.0
|
||||
- ``os.walk()``
|
||||
|
||||
* - ``sphinx.util.pycompat.u``
|
||||
- 2.0
|
||||
- 4.0
|
||||
- N/A
|
||||
|
||||
* - ``sphinx.application.Sphinx._setting_up_extension``
|
||||
- 2.0
|
||||
- 3.0
|
||||
- N/A
|
||||
|
||||
* - ``sphinx.writers.latex.LaTeXTranslator.babel_defmacro()``
|
||||
- 2.0
|
||||
- 4.0
|
||||
- N/A
|
||||
|
||||
* - :rst:dir:`highlightlang`
|
||||
- 1.8
|
||||
- 4.0
|
||||
- :rst:dir:`highlight`
|
||||
|
||||
* - :meth:`~sphinx.application.Sphinx.add_stylesheet()`
|
||||
- 1.8
|
||||
- 4.0
|
||||
- :meth:`~sphinx.application.Sphinx.add_css_file()`
|
||||
|
||||
* - :meth:`~sphinx.application.Sphinx.add_javascript()`
|
||||
- 1.8
|
||||
- 4.0
|
||||
- :meth:`~sphinx.application.Sphinx.add_js_file()`
|
||||
|
||||
* - :confval:`autodoc_default_flags`
|
||||
- 1.8
|
||||
- 4.0
|
||||
- :confval:`autodoc_default_options`
|
||||
|
||||
* - ``content`` arguments of ``sphinx.util.image.guess_mimetype()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- N/A
|
||||
|
||||
* - ``gettext_compact`` arguments of
|
||||
``sphinx.util.i18n.find_catalog_source_files()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- N/A
|
||||
|
||||
* - ``sphinx.io.SphinxI18nReader.set_lineno_for_reporter()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- N/A
|
||||
|
||||
* - ``sphinx.io.SphinxI18nReader.line``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- N/A
|
||||
|
||||
* - ``sphinx.directives.other.VersionChanges``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- ``sphinx.domains.changeset.VersionChanges``
|
||||
|
||||
* - ``sphinx.highlighting.PygmentsBridge.unhighlight()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- N/A
|
||||
|
||||
* - ``trim_doctest_flags`` arguments of
|
||||
``sphinx.highlighting.PygmentsBridge``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- N/A
|
||||
|
||||
* - ``sphinx.ext.mathbase``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- N/A
|
||||
|
||||
* - ``sphinx.ext.mathbase.MathDomain``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- ``sphinx.domains.math.MathDomain``
|
||||
|
||||
* - ``sphinx.ext.mathbase.MathDirective``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- ``sphinx.directives.patches.MathDirective``
|
||||
|
||||
* - ``sphinx.ext.mathbase.math_role()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- ``docutils.parsers.rst.roles.math_role()``
|
||||
|
||||
* - ``sphinx.ext.mathbase.setup_math()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- :meth:`~sphinx.application.Sphinx.add_html_math_renderer()`
|
||||
|
||||
* - ``sphinx.ext.mathbase.is_in_section_title()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- N/A
|
||||
|
||||
* - ``sphinx.ext.mathbase.get_node_equation_number()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- ``sphinx.util.math.get_node_equation_number()``
|
||||
|
||||
* - ``sphinx.ext.mathbase.wrap_displaymath()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- ``sphinx.util.math.wrap_displaymath()``
|
||||
|
||||
* - ``sphinx.ext.mathbase.math`` (node)
|
||||
- 1.8
|
||||
- 3.0
|
||||
- ``docutils.nodes.math``
|
||||
|
||||
* - ``sphinx.ext.mathbase.displaymath`` (node)
|
||||
- 1.8
|
||||
- 3.0
|
||||
- ``docutils.nodes.math_block``
|
||||
|
||||
* - ``sphinx.ext.mathbase.eqref`` (node)
|
||||
- 1.8
|
||||
- 3.0
|
||||
- ``sphinx.builders.latex.nodes.math_reference``
|
||||
|
||||
* - ``viewcode_import`` (config value)
|
||||
- 1.8
|
||||
- 3.0
|
||||
- :confval:`viewcode_follow_imported_members`
|
||||
|
||||
* - ``sphinx.writers.latex.Table.caption_footnotetexts``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- N/A
|
||||
|
||||
* - ``sphinx.writers.latex.Table.header_footnotetexts``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- N/A
|
||||
|
||||
* - ``sphinx.writers.latex.LaTeXTranslator.footnotestack``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- N/A
|
||||
|
||||
* - ``sphinx.writers.latex.LaTeXTranslator.in_container_literal_block``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- N/A
|
||||
|
||||
* - ``sphinx.writers.latex.LaTeXTranslator.next_section_ids``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- N/A
|
||||
|
||||
* - ``sphinx.writers.latex.LaTeXTranslator.next_hyperlink_ids``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- N/A
|
||||
|
||||
* - ``sphinx.writers.latex.LaTeXTranslator.restrict_footnote()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- N/A
|
||||
|
||||
* - ``sphinx.writers.latex.LaTeXTranslator.unrestrict_footnote()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- N/A
|
||||
|
||||
* - ``sphinx.writers.latex.LaTeXTranslator.push_hyperlink_ids()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- N/A
|
||||
|
||||
* - ``sphinx.writers.latex.LaTeXTranslator.pop_hyperlink_ids()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- N/A
|
||||
|
||||
* - ``sphinx.writers.latex.LaTeXTranslator.bibitems``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- N/A
|
||||
|
||||
* - ``sphinx.writers.latex.LaTeXTranslator.hlsettingstack``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- N/A
|
||||
|
||||
* - ``sphinx.writers.latex.ExtBabel.get_shorthandoff()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- N/A
|
||||
|
||||
* - ``sphinx.writers.html.HTMLTranslator.highlightlang()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- N/A
|
||||
|
||||
* - ``sphinx.writers.html.HTMLTranslator.highlightlang_base()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- N/A
|
||||
|
||||
* - ``sphinx.writers.html.HTMLTranslator.highlightlangopts()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- N/A
|
||||
|
||||
* - ``sphinx.writers.html.HTMLTranslator.highlightlinenothreshold()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- N/A
|
||||
|
||||
* - ``sphinx.writers.html5.HTMLTranslator.highlightlang()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- N/A
|
||||
|
||||
* - ``sphinx.writers.html5.HTMLTranslator.highlightlang_base()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- N/A
|
||||
|
||||
* - ``sphinx.writers.html5.HTMLTranslator.highlightlangopts()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- N/A
|
||||
|
||||
* - ``sphinx.writers.html5.HTMLTranslator.highlightlinenothreshold()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- N/A
|
||||
|
||||
* - ``sphinx.writers.latex.LaTeXTranslator.check_latex_elements()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- Nothing
|
||||
|
||||
* - ``sphinx.application.CONFIG_FILENAME``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- ``sphinx.config.CONFIG_FILENAME``
|
||||
|
||||
* - ``Config.check_unicode()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- ``sphinx.config.check_unicode()``
|
||||
|
||||
* - ``Config.check_types()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- ``sphinx.config.check_confval_types()``
|
||||
|
||||
* - ``dirname``, ``filename`` and ``tags`` arguments of
|
||||
``Config.__init__()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- ``Config.read()``
|
||||
|
||||
* - The value of :confval:`html_search_options`
|
||||
- 1.8
|
||||
- 3.0
|
||||
- see :confval:`html_search_options`
|
||||
|
||||
* - ``sphinx.versioning.prepare()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- ``sphinx.versioning.UIDTransform``
|
||||
|
||||
* - ``Sphinx.override_domain()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- :meth:`~sphinx.application.Sphinx.add_domain()`
|
||||
|
||||
* - ``Sphinx.import_object()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- ``sphinx.util.import_object()``
|
||||
|
||||
* - ``suffix`` argument of
|
||||
:meth:`~sphinx.application.Sphinx.add_source_parser()`
|
||||
- 1.8
|
||||
- 3.0
|
||||
- :meth:`~sphinx.application.Sphinx.add_source_suffix()`
|
||||
|
||||
|
||||
* - ``BuildEnvironment.load()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- ``pickle.load()``
|
||||
|
||||
* - ``BuildEnvironment.loads()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- ``pickle.loads()``
|
||||
|
||||
* - ``BuildEnvironment.frompickle()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- ``pickle.load()``
|
||||
|
||||
* - ``BuildEnvironment.dump()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- ``pickle.dump()``
|
||||
|
||||
* - ``BuildEnvironment.dumps()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- ``pickle.dumps()``
|
||||
|
||||
* - ``BuildEnvironment.topickle()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- ``pickle.dump()``
|
||||
|
||||
* - ``BuildEnvironment._nitpick_ignore``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- :confval:`nitpick_ignore`
|
||||
|
||||
* - ``BuildEnvironment.versionchanges``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- N/A
|
||||
|
||||
* - ``BuildEnvironment.update()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- ``Builder.read()``
|
||||
|
||||
* - ``BuildEnvironment.read_doc()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- ``Builder.read_doc()``
|
||||
|
||||
* - ``BuildEnvironment._read_serial()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- ``Builder.read()``
|
||||
|
||||
* - ``BuildEnvironment._read_parallel()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- ``Builder.read()``
|
||||
|
||||
* - ``BuildEnvironment.write_doctree()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- ``Builder.write_doctree()``
|
||||
|
||||
* - ``BuildEnvironment.note_versionchange()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- ``ChangesDomain.note_changeset()``
|
||||
|
||||
* - ``warn()`` (template helper function)
|
||||
- 1.8
|
||||
- 3.0
|
||||
- ``warning()``
|
||||
|
||||
* - :confval:`source_parsers`
|
||||
- 1.8
|
||||
- 3.0
|
||||
- :meth:`~sphinx.application.Sphinx.add_source_parser()`
|
||||
|
||||
* - ``sphinx.util.docutils.directive_helper()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- ``Directive`` class of docutils
|
||||
|
||||
* - ``sphinx.cmdline``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- ``sphinx.cmd.build``
|
||||
|
||||
* - ``sphinx.make_mode``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- ``sphinx.cmd.make_mode``
|
||||
|
||||
* - ``sphinx.locale.l_()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- :func:`sphinx.locale._()`
|
||||
|
||||
* - ``sphinx.locale.lazy_gettext()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- :func:`sphinx.locale._()`
|
||||
|
||||
* - ``sphinx.locale.mygettext()``
|
||||
- 1.8
|
||||
- 3.0
|
||||
- :func:`sphinx.locale._()`
|
||||
|
||||
* - ``sphinx.util.copy_static_entry()``
|
||||
- 1.5
|
||||
- 3.0
|
||||
- ``sphinx.util.fileutil.copy_asset()``
|
||||
|
||||
* - ``sphinx.build_main()``
|
||||
- 1.7
|
||||
- 2.0
|
||||
- ``sphinx.cmd.build.build_main()``
|
||||
|
||||
* - ``sphinx.ext.intersphinx.debug()``
|
||||
- 1.7
|
||||
- 2.0
|
||||
- ``sphinx.ext.intersphinx.inspect_main()``
|
||||
|
||||
* - ``sphinx.ext.autodoc.format_annotation()``
|
||||
- 1.7
|
||||
- 2.0
|
||||
- ``sphinx.util.inspect.Signature``
|
||||
|
||||
* - ``sphinx.ext.autodoc.formatargspec()``
|
||||
- 1.7
|
||||
- 2.0
|
||||
- ``sphinx.util.inspect.Signature``
|
||||
|
||||
* - ``sphinx.ext.autodoc.AutodocReporter``
|
||||
- 1.7
|
||||
- 2.0
|
||||
- ``sphinx.util.docutils.switch_source_input()``
|
||||
|
||||
* - ``sphinx.ext.autodoc.add_documenter()``
|
||||
- 1.7
|
||||
- 2.0
|
||||
- :meth:`~sphinx.application.Sphinx.add_autodocumenter()`
|
||||
|
||||
* - ``sphinx.ext.autodoc.AutoDirective._register``
|
||||
- 1.7
|
||||
- 2.0
|
||||
- :meth:`~sphinx.application.Sphinx.add_autodocumenter()`
|
||||
|
||||
* - ``AutoDirective._special_attrgetters``
|
||||
- 1.7
|
||||
- 2.0
|
||||
- :meth:`~sphinx.application.Sphinx.add_autodoc_attrgetter()`
|
||||
|
||||
* - ``Sphinx.warn()``, ``Sphinx.info()``
|
||||
- 1.6
|
||||
- 2.0
|
||||
- :ref:`logging-api`
|
||||
|
||||
* - ``BuildEnvironment.set_warnfunc()``
|
||||
- 1.6
|
||||
- 2.0
|
||||
- :ref:`logging-api`
|
||||
|
||||
* - ``BuildEnvironment.note_toctree()``
|
||||
- 1.6
|
||||
- 2.0
|
||||
- ``Toctree.note()`` (in ``sphinx.environment.adapters.toctree``)
|
||||
|
||||
* - ``BuildEnvironment.get_toc_for()``
|
||||
- 1.6
|
||||
- 2.0
|
||||
- ``Toctree.get_toc_for()`` (in ``sphinx.environment.adapters.toctree``)
|
||||
|
||||
* - ``BuildEnvironment.get_toctree_for()``
|
||||
- 1.6
|
||||
- 2.0
|
||||
- ``Toctree.get_toctree_for()`` (in ``sphinx.environment.adapters.toctree``)
|
||||
|
||||
* - ``BuildEnvironment.create_index()``
|
||||
- 1.6
|
||||
- 2.0
|
||||
- ``IndexEntries.create_index()`` (in ``sphinx.environment.adapters.indexentries``)
|
||||
|
||||
* - ``sphinx.websupport``
|
||||
- 1.6
|
||||
- 2.0
|
||||
- `sphinxcontrib-websupport <https://pypi.org/project/sphinxcontrib-websupport/>`_
|
||||
|
||||
* - ``StandaloneHTMLBuilder.css_files``
|
||||
- 1.6
|
||||
- 2.0
|
||||
- :meth:`~sphinx.application.Sphinx.add_stylesheet()`
|
||||
|
||||
* - ``document.settings.gettext_compact``
|
||||
- 1.8
|
||||
- 1.8
|
||||
- :confval:`gettext_compact`
|
||||
|
||||
* - ``Sphinx.status_iterator()``
|
||||
- 1.6
|
||||
- 1.7
|
||||
- ``sphinx.util.status_iterator()``
|
||||
|
||||
* - ``Sphinx.old_status_iterator()``
|
||||
- 1.6
|
||||
- 1.7
|
||||
- ``sphinx.util.old_status_iterator()``
|
||||
|
||||
* - ``Sphinx._directive_helper()``
|
||||
- 1.6
|
||||
- 1.7
|
||||
- ``sphinx.util.docutils.directive_helper()``
|
||||
|
||||
* - ``sphinx.util.compat.Directive``
|
||||
- 1.6
|
||||
- 1.7
|
||||
- ``docutils.parsers.rst.Directive``
|
||||
|
||||
* - ``sphinx.util.compat.docutils_version``
|
||||
- 1.6
|
||||
- 1.7
|
||||
- ``sphinx.util.docutils.__version_info__``
|
||||
|
||||
.. note:: On deprecating on public APIs (internal functions and classes),
|
||||
we also follow the policy as much as possible.
|
||||
+21
-32
@@ -3,22 +3,15 @@
|
||||
Logging API
|
||||
===========
|
||||
|
||||
.. function:: sphinx.util.logging.getLogger(name)
|
||||
.. currentmodule:: sphinx.util.logging
|
||||
|
||||
Returns a logger wrapped by :class:`SphinxLoggerAdapter` with the specified *name*.
|
||||
.. autofunction:: getLogger(name)
|
||||
|
||||
Example usage::
|
||||
.. autoclass:: SphinxLoggerAdapter(logging.LoggerAdapter)
|
||||
|
||||
from sphinx.util import logging # Load on top of python's logging module
|
||||
|
||||
logger = logging.getLogger(__name__)
|
||||
logger.info('Hello, this is an extension!')
|
||||
|
||||
.. class:: SphinxLoggerAdapter(logging.LoggerAdapter)
|
||||
|
||||
.. method:: SphinxLoggerAdapter.error(level, msg, *args, **kwargs)
|
||||
.. method:: SphinxLoggerAdapter.critical(level, msg, *args, **kwargs)
|
||||
.. method:: SphinxLoggerAdapter.warning(level, msg, *args, **kwargs)
|
||||
.. method:: SphinxLoggerAdapter.error(msg, *args, **kwargs)
|
||||
.. method:: SphinxLoggerAdapter.critical(msg, *args, **kwargs)
|
||||
.. method:: SphinxLoggerAdapter.warning(msg, *args, **kwargs)
|
||||
|
||||
Logs a message on this logger with the specified level.
|
||||
Basically, the arguments are as with python's logging module.
|
||||
@@ -40,13 +33,14 @@ Logging API
|
||||
logger.warning('Warning happened!', location=some_node)
|
||||
|
||||
**color**
|
||||
The color of logs. By default, warning level logs are
|
||||
colored as ``"darkred"``. The others are not colored.
|
||||
The color of logs. By default, error level logs are colored as
|
||||
``"darkred"``, critical level ones is not colored, and warning level
|
||||
ones are colored as ``"red"``.
|
||||
|
||||
.. method:: SphinxLoggerAdapter.log(level, msg, *args, **kwargs)
|
||||
.. method:: SphinxLoggerAdapter.info(level, msg, *args, **kwargs)
|
||||
.. method:: SphinxLoggerAdapter.verbose(level, msg, *args, **kwargs)
|
||||
.. method:: SphinxLoggerAdapter.debug(level, msg, *args, **kwargs)
|
||||
.. method:: SphinxLoggerAdapter.info(msg, *args, **kwargs)
|
||||
.. method:: SphinxLoggerAdapter.verbose(msg, *args, **kwargs)
|
||||
.. method:: SphinxLoggerAdapter.debug(msg, *args, **kwargs)
|
||||
|
||||
Logs a message to this logger with the specified level.
|
||||
Basically, the arguments are as with python's logging module.
|
||||
@@ -57,21 +51,16 @@ Logging API
|
||||
If true, the logger does not fold lines at the end of the log message.
|
||||
The default is ``False``.
|
||||
|
||||
**location**
|
||||
Where the message emitted. For more detail, see
|
||||
:meth:`SphinxLoggerAdapter.warning`.
|
||||
|
||||
**color**
|
||||
The color of logs. By default, debug level logs are
|
||||
colored as ``"darkgray"``, and debug2 level ones are ``"lightgray"``.
|
||||
The others are not colored.
|
||||
The color of logs. By default, info and verbose level logs are not colored,
|
||||
and deug level ones are colored as ``"darkgray"``.
|
||||
|
||||
.. function:: pending_logging()
|
||||
.. autofunction:: pending_logging()
|
||||
|
||||
Marks all logs as pending::
|
||||
.. autofunction:: pending_warnings()
|
||||
|
||||
with pending_logging():
|
||||
logger.warning('Warning message!') # not flushed yet
|
||||
some_long_process()
|
||||
|
||||
# the warning is flushed here
|
||||
|
||||
.. function:: pending_warnings()
|
||||
|
||||
Marks warning logs as pending. Similar to :func:`pending_logging`.
|
||||
.. autofunction:: prefixed_warnings()
|
||||
+20
-10
@@ -70,14 +70,6 @@ using :meth:`.Sphinx.add_directive` or :meth:`.Sphinx.add_directive_to_domain`.
|
||||
The absolute line number on which the directive appeared. This is not
|
||||
always a useful value; use :attr:`srcline` instead.
|
||||
|
||||
.. attribute:: src
|
||||
|
||||
The source file of the directive.
|
||||
|
||||
.. attribute:: srcline
|
||||
|
||||
The line number in the source file on which the directive appeared.
|
||||
|
||||
.. attribute:: content_offset
|
||||
|
||||
Internal offset of the directive content. Used when calling
|
||||
@@ -125,12 +117,30 @@ Both APIs parse the content into a given node. They are used like this::
|
||||
|
||||
node = docutils.nodes.paragraph()
|
||||
# either
|
||||
from sphinx.ext.autodoc import AutodocReporter
|
||||
self.state.memo.reporter = AutodocReporter(self.result, self.state.memo.reporter) # override reporter to avoid errors from "include" directive
|
||||
nested_parse_with_titles(self.state, self.result, node)
|
||||
# or
|
||||
self.state.nested_parse(self.result, 0, node)
|
||||
|
||||
.. note::
|
||||
|
||||
``sphinx.util.docutils.switch_source_input()`` allows to change a target file
|
||||
during nested_parse. It is useful to mixed contents. For example, ``sphinx.
|
||||
ext.autodoc`` uses it to parse docstrings::
|
||||
|
||||
from sphinx.util.docutils import switch_source_input
|
||||
|
||||
# Switch source_input between parsing content.
|
||||
# Inside this context, all parsing errors and warnings are reported as
|
||||
# happened in new source_input (in this case, ``self.result``).
|
||||
with switch_source_input(self.state, self.result):
|
||||
node = docutils.nodes.paragraph()
|
||||
self.state.nested_parse(self.result, 0, node)
|
||||
|
||||
.. deprecated:: 1.7
|
||||
|
||||
Until Sphinx-1.6, ``sphinx.ext.autodoc.AutodocReporter`` is used for this purpose.
|
||||
For now, it is replaced by ``switch_source_input()``.
|
||||
|
||||
If you don't need the wrapping node, you can use any concrete node type and
|
||||
return ``node.children`` from the Directive.
|
||||
|
||||
|
||||
@@ -3,6 +3,35 @@
|
||||
Parser API
|
||||
==========
|
||||
|
||||
`The docutils documentation describes`__ parsers as follows:
|
||||
|
||||
The Parser analyzes the input document and creates a node tree
|
||||
representation.
|
||||
|
||||
__ http://docutils.sourceforge.net/docs/dev/hacking.html#parsing-the-document
|
||||
|
||||
In Sphinx, the parser modules works as same as docutils. The parsers are
|
||||
registered to Sphinx by extensions using Application APIs;
|
||||
:meth:`.Sphinx.add_source_suffix()` and :meth:`.Sphinx.add_source_parser()`.
|
||||
|
||||
The *source suffix* is a mapping from file suffix to file type. For example,
|
||||
``.rst`` file is mapped to ``'restructuredtext'`` type. Sphinx uses the
|
||||
file type to looking for parsers from registered list. On searching,
|
||||
Sphinx refers to the ``Parser.supported`` attribute and picks up a parser
|
||||
which contains the file type in the attribute.
|
||||
|
||||
The users can override the source suffix mappings using
|
||||
:confval:`source_suffix` like following::
|
||||
|
||||
# a mapping from file suffix to file types
|
||||
source_suffix = {
|
||||
'.rst': 'restructuredtext',
|
||||
'.md': 'markdown',
|
||||
}
|
||||
|
||||
You should indicate file types your parser supports. This will allow users
|
||||
to configure their settings appropriately.
|
||||
|
||||
.. module:: sphinx.parsers
|
||||
|
||||
.. autoclass:: Parser
|
||||
@@ -0,0 +1,9 @@
|
||||
.. _project-api:
|
||||
|
||||
Project API
|
||||
===========
|
||||
|
||||
.. currentmodule:: sphinx.project
|
||||
|
||||
.. autoclass:: Project
|
||||
:members:
|
||||
@@ -0,0 +1,22 @@
|
||||
Utilities
|
||||
=========
|
||||
|
||||
Sphinx provides utility classes and functions to develop extensions.
|
||||
|
||||
Base classes for components
|
||||
---------------------------
|
||||
|
||||
These base classes are useful to allow your extensions to obtain Sphinx
|
||||
components (e.g. :class:`.Config`, :class:`.BuildEnvironment` and so on) easily.
|
||||
|
||||
.. note:: The subclasses of them might not work with bare docutils because they
|
||||
are strongly coupled with Sphinx.
|
||||
|
||||
.. autoclass:: sphinx.transforms.SphinxTransform
|
||||
:members:
|
||||
|
||||
.. autoclass:: sphinx.util.docutils.SphinxDirective
|
||||
:members:
|
||||
|
||||
.. autoclass:: sphinx.transforms.post_transforms.images.ImageConverter
|
||||
:members:
|
||||
@@ -1,16 +0,0 @@
|
||||
.. _extensions:
|
||||
|
||||
Sphinx Extensions
|
||||
=================
|
||||
|
||||
Since many projects will need special features in their documentation, Sphinx
|
||||
allows adding "extensions" to the build process, each of which can modify almost
|
||||
any aspect of document processing.
|
||||
|
||||
This chapter describes the extensions bundled with Sphinx. For the API
|
||||
documentation on writing your own extension, see :ref:`dev-extensions`.
|
||||
|
||||
.. toctree::
|
||||
|
||||
ext/builtins
|
||||
ext/thirdparty
|
||||
+9
-12
@@ -11,22 +11,19 @@ How do I...
|
||||
|
||||
... create PDF files without LaTeX?
|
||||
`rinohtype`_ provides a PDF builder that can be used as a drop-in
|
||||
replacement for the LaTeX builder. Alternatively, you can use `rst2pdf`_
|
||||
version 0.12 or greater which comes with built-in Sphinx integration. See
|
||||
the :ref:`builders` section for details.
|
||||
replacement for the LaTeX builder.
|
||||
|
||||
.. _rinohtype: https://github.com/brechtm/rinohtype
|
||||
.. _rst2pdf: https://github.com/rst2pdf/rst2pdf
|
||||
|
||||
... get section numbers?
|
||||
They are automatic in LaTeX output; for HTML, give a ``:numbered:`` option to
|
||||
the :rst:dir:`toctree` directive where you want to start numbering.
|
||||
|
||||
... customize the look of the built HTML files?
|
||||
Use themes, see :doc:`theming`.
|
||||
Use themes, see :doc:`/usage/theming`.
|
||||
|
||||
... add global substitutions or includes?
|
||||
Add them in the :confval:`rst_epilog` config value.
|
||||
Add them in the :confval:`rst_prolog` or :confval:`rst_epilog` config value.
|
||||
|
||||
... display the whole TOC tree in the sidebar?
|
||||
Use the :data:`toctree` callable in a custom layout template, probably in the
|
||||
@@ -58,7 +55,7 @@ Read the Docs
|
||||
Sphinx. They will host sphinx documentation, along with supporting a number
|
||||
of other features including version support, PDF generation, and more. The
|
||||
`Getting Started
|
||||
<http://read-the-docs.readthedocs.org/en/latest/getting_started.html>`_
|
||||
<https://read-the-docs.readthedocs.io/en/latest/getting_started.html>`_
|
||||
guide is a good place to start.
|
||||
|
||||
Epydoc
|
||||
@@ -75,9 +72,9 @@ SCons
|
||||
|
||||
PyPI
|
||||
Jannis Leidel wrote a `setuptools command
|
||||
<https://pypi.python.org/pypi/Sphinx-PyPI-upload>`_ that automatically
|
||||
<https://pypi.org/project/Sphinx-PyPI-upload/>`_ that automatically
|
||||
uploads Sphinx documentation to the PyPI package documentation area at
|
||||
http://pythonhosted.org/.
|
||||
https://pythonhosted.org/.
|
||||
|
||||
GitHub Pages
|
||||
Directories starting with underscores are ignored by default which breaks
|
||||
@@ -106,7 +103,7 @@ Google Analytics
|
||||
|
||||
{% block footer %}
|
||||
{{ super() }}
|
||||
<div class="footer">This page uses <a href="http://analytics.google.com/">
|
||||
<div class="footer">This page uses <a href="https://analytics.google.com/">
|
||||
Google Analytics</a> to collect statistics. You can disable it by blocking
|
||||
the JavaScript coming from www.google-analytics.com.
|
||||
<script type="text/javascript">
|
||||
@@ -122,7 +119,7 @@ Google Analytics
|
||||
{% endblock %}
|
||||
|
||||
|
||||
.. _api role: http://git.savannah.gnu.org/cgit/kenozooid.git/tree/doc/extapi.py
|
||||
.. _api role: https://git.savannah.gnu.org/cgit/kenozooid.git/tree/doc/extapi.py
|
||||
.. _xhtml to reST: http://docutils.sourceforge.net/sandbox/xhtml2rest/xhtml2rest.py
|
||||
|
||||
|
||||
@@ -208,7 +205,7 @@ The following list gives some hints for the creation of epub files:
|
||||
.. _Epubcheck: https://github.com/IDPF/epubcheck
|
||||
.. _Calibre: https://calibre-ebook.com/
|
||||
.. _FBreader: https://fbreader.org/
|
||||
.. _Bookworm: http://www.oreilly.com/bookworm/index.html
|
||||
.. _Bookworm: https://www.oreilly.com/bookworm/index.html
|
||||
.. _kindlegen: https://www.amazon.com/gp/feature.html?docId=1000765211
|
||||
|
||||
.. _texinfo-faq:
|
||||
|
||||
+17
-5
@@ -12,7 +12,8 @@ Glossary
|
||||
use the builder builders that e.g. check for broken links in the
|
||||
documentation, or build coverage information.
|
||||
|
||||
See :ref:`builders` for an overview over Sphinx's built-in builders.
|
||||
See :doc:`/usage/builders/index` for an overview over Sphinx's built-in
|
||||
builders.
|
||||
|
||||
configuration directory
|
||||
The directory containing :file:`conf.py`. By default, this is the same as
|
||||
@@ -32,7 +33,7 @@ Glossary
|
||||
|
||||
Content of the directive.
|
||||
|
||||
See :ref:`directives` for more information.
|
||||
See :ref:`rst-directives` for more information.
|
||||
|
||||
document name
|
||||
Since reST source files can have different extensions (some people like
|
||||
@@ -56,8 +57,9 @@ Glossary
|
||||
Having domains means that there are no naming problems when one set of
|
||||
documentation wants to refer to e.g. C++ and Python classes. It also
|
||||
means that extensions that support the documentation of whole new
|
||||
languages are much easier to write. For more information about domains,
|
||||
see the chapter :ref:`domains`.
|
||||
languages are much easier to write.
|
||||
|
||||
For more information, refer to :doc:`/usage/restructuredtext/domains`.
|
||||
|
||||
environment
|
||||
A structure where information about all documents under the root is saved,
|
||||
@@ -65,6 +67,12 @@ Glossary
|
||||
parsing stage, so that successive runs only need to read and parse new and
|
||||
changed documents.
|
||||
|
||||
extension
|
||||
A custom :term:`role`, :term:`directive` or other aspect of Sphinx that
|
||||
allows users to modify any aspect of the build process within Sphinx.
|
||||
|
||||
For more information, refer to :doc:`/usage/extensions/index`.
|
||||
|
||||
master document
|
||||
The document that contains the root :rst:dir:`toctree` directive.
|
||||
|
||||
@@ -81,8 +89,12 @@ Glossary
|
||||
role
|
||||
A reStructuredText markup element that allows marking a piece of text.
|
||||
Like directives, roles are extensible. The basic syntax looks like this:
|
||||
``:rolename:`content```. See :ref:`inlinemarkup` for details.
|
||||
``:rolename:`content```. See :ref:`rst-inline-markup` for details.
|
||||
|
||||
source directory
|
||||
The directory which, including its subdirectories, contains all source
|
||||
files for one Sphinx project.
|
||||
|
||||
reStructuredText
|
||||
An easy-to-read, what-you-see-is-what-you-get plaintext markup syntax and
|
||||
parser system.
|
||||
-155
@@ -1,155 +0,0 @@
|
||||
:orphan:
|
||||
|
||||
Installing Sphinx
|
||||
=================
|
||||
|
||||
Since Sphinx is written in the Python language, you need to install Python
|
||||
(the required version is at least 2.7) and Sphinx.
|
||||
|
||||
Sphinx packages are available on the `Python Package Index
|
||||
<https://pypi.python.org/pypi/Sphinx>`_.
|
||||
|
||||
You can also download a snapshot from the Git repository:
|
||||
|
||||
* as a `.tar.gz <https://github.com/sphinx-doc/sphinx/archive/master.tar.gz>`__
|
||||
file or
|
||||
* as a `.zip <https://github.com/sphinx-doc/sphinx/archive/master.zip>`_ file
|
||||
|
||||
There are introductions for several environments:
|
||||
|
||||
.. contents::
|
||||
:depth: 1
|
||||
:local:
|
||||
:backlinks: none
|
||||
|
||||
|
||||
Debian/Ubuntu: Install Sphinx using packaging system
|
||||
----------------------------------------------------
|
||||
|
||||
You may install using this command if you use Debian/Ubuntu.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ apt-get install python-sphinx
|
||||
|
||||
|
||||
Other Linux distributions
|
||||
-------------------------
|
||||
|
||||
Most Linux distributions have Sphinx in their package repositories. Usually the
|
||||
package is called "python-sphinx", "python-Sphinx" or "sphinx". Be aware that
|
||||
there are two other packages with "sphinx" in their name: a speech recognition
|
||||
toolkit (CMU Sphinx) and a full-text search database (Sphinx search).
|
||||
|
||||
|
||||
Mac OS X: Install Sphinx using MacPorts
|
||||
---------------------------------------
|
||||
|
||||
If you use Mac OS X `MacPorts <http://www.macports.org/>`_, use this command to
|
||||
install all necessary software.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ sudo port install py27-sphinx
|
||||
|
||||
To set up the executable paths, use the ``port select`` command:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ sudo port select --set python python27
|
||||
$ sudo port select --set sphinx py27-sphinx
|
||||
|
||||
Type :command:`which sphinx-quickstart` to check if the installation was
|
||||
successful.
|
||||
|
||||
|
||||
Windows: Install Python and Sphinx
|
||||
----------------------------------
|
||||
|
||||
Install Python
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
Most Windows users do not have Python, so we begin with the installation of
|
||||
Python itself. If you have already installed Python, please skip this section.
|
||||
|
||||
Go to https://www.python.org/, the main download site for Python. Look at the left
|
||||
sidebar and under "Quick Links", click "Windows Installer" to download.
|
||||
|
||||
.. image:: pythonorg.png
|
||||
|
||||
.. note::
|
||||
|
||||
Currently, Python offers two major versions, 2.x and 3.x. Sphinx 1.5 can run
|
||||
under Python 2.7, 3.4, 3.5, 3.6, with the recommended version being 2.7. This
|
||||
chapter assumes you have installed Python 2.7.
|
||||
|
||||
Follow the Windows installer for Python.
|
||||
|
||||
.. image:: installpython.jpg
|
||||
|
||||
After installation, you better add the Python executable directories to the
|
||||
environment variable ``PATH`` in order to run Python and package commands such
|
||||
as ``sphinx-build`` easily from the Command Prompt.
|
||||
|
||||
* Right-click the "My Computer" icon and choose "Properties"
|
||||
* Click the "Environment Variables" button under the "Advanced" tab
|
||||
|
||||
* If "Path" (or "PATH") is already an entry in the "System variables" list, edit
|
||||
it. If it is not present, add a new variable called "PATH".
|
||||
|
||||
* Add these paths, separating entries by ";":
|
||||
|
||||
- ``C:\Python27`` -- this folder contains the main Python executable
|
||||
- ``C:\Python27\Scripts`` -- this folder will contain executables added by
|
||||
Python packages installed with pip (see below)
|
||||
|
||||
This is for Python 2.7. If you use another version of
|
||||
Python or installed to a non-default location, change the digits "27"
|
||||
accordingly.
|
||||
|
||||
* Now run the **Command Prompt**. After command prompt window appear, type
|
||||
``python`` and Enter. If the Python installation was successful, the
|
||||
installed Python version is printed, and you are greeted by the prompt
|
||||
``>>>``. Type ``Ctrl+Z`` and Enter to quit.
|
||||
|
||||
|
||||
Install the pip command
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Python has a very useful :command:`pip` command which can download and install
|
||||
3rd-party libraries with a single command. This is provided by the
|
||||
Python Packaging Authority(PyPA):
|
||||
https://groups.google.com/forum/#!forum/pypa-dev
|
||||
|
||||
To install pip, download https://bootstrap.pypa.io/get-pip.py and
|
||||
save it somewhere. After download, invoke the command prompt, go to the
|
||||
directory with ``get-pip.py`` and run this command:
|
||||
|
||||
.. code-block:: bat
|
||||
|
||||
C:\> python get-pip.py
|
||||
|
||||
Now :command:`pip` command is installed. From there we can go to the Sphinx
|
||||
install.
|
||||
|
||||
.. note::
|
||||
|
||||
``pip`` has been contained in the Python official installation after version
|
||||
of Python-3.4.0 or Python-2.7.9.
|
||||
|
||||
|
||||
Installing Sphinx with pip
|
||||
--------------------------
|
||||
|
||||
If you finished the installation of pip, type this line in the command prompt:
|
||||
|
||||
.. code-block:: bat
|
||||
|
||||
C:\> pip install sphinx
|
||||
|
||||
After installation, type :command:`sphinx-build -h` on the command prompt. If
|
||||
everything worked fine, you will get a Sphinx version number and a list of
|
||||
options for this command.
|
||||
|
||||
That it. Installation is over. Head to :doc:`tutorial` to make a Sphinx
|
||||
project.
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 25 KiB |
+13
-16
@@ -3,12 +3,12 @@ Introduction
|
||||
|
||||
This is the documentation for the Sphinx documentation builder. Sphinx is a
|
||||
tool that translates a set of reStructuredText_ source files into various output
|
||||
formats, automatically producing cross-references, indices etc. That is, if
|
||||
formats, automatically producing cross-references, indices, etc. That is, if
|
||||
you have a directory containing a bunch of reST-formatted documents (and
|
||||
possibly subdirectories of docs in there as well), Sphinx can generate a
|
||||
nicely-organized arrangement of HTML files (in some other directory) for easy
|
||||
browsing and navigation. But from the same source, it can also generate a PDF
|
||||
file using LaTeX, `rinohtype`_ or `rst2pdf`_ (see :ref:`builders`).
|
||||
file using LaTeX.
|
||||
|
||||
The focus is on hand-written documentation, rather than auto-generated API docs.
|
||||
Though there is support for that kind of documentation as well (which is
|
||||
@@ -17,11 +17,10 @@ docs have a look at `Epydoc <http://epydoc.sourceforge.net/>`_, which also
|
||||
understands reST.
|
||||
|
||||
For a great "introduction" to writing docs in general -- the whys and hows, see
|
||||
also `Write the docs <http://write-the-docs.readthedocs.org/>`_, written by Eric
|
||||
also `Write the docs <https://write-the-docs.readthedocs.io/>`_, written by Eric
|
||||
Holscher.
|
||||
|
||||
.. _rinohtype: https://github.com/brechtm/rinohtype
|
||||
.. _rst2pdf: https://github.com/rst2pdf/rst2pdf
|
||||
|
||||
Conversion from other systems
|
||||
-----------------------------
|
||||
@@ -30,20 +29,20 @@ This section is intended to collect helpful hints for those wanting to migrate
|
||||
to reStructuredText/Sphinx from other documentation systems.
|
||||
|
||||
* Gerard Flanagan has written a script to convert pure HTML to reST; it can be
|
||||
found at the `Python Package Index <https://pypi.python.org/pypi/html2rest>`_.
|
||||
found at the `Python Package Index <https://pypi.org/project/html2rest/>`_.
|
||||
|
||||
* For converting the old Python docs to Sphinx, a converter was written which
|
||||
can be found at `the Python SVN repository
|
||||
<http://svn.python.org/projects/doctools/converter>`_. It contains generic
|
||||
<https://svn.python.org/projects/doctools/converter/>`_. It contains generic
|
||||
code to convert Python-doc-style LaTeX markup to Sphinx reST.
|
||||
|
||||
* Marcin Wojdyr has written a script to convert Docbook to reST with Sphinx
|
||||
markup; it is at `Google Code <https://github.com/wojdyr/db2rst>`_.
|
||||
markup; it is at `GitHub <https://github.com/wojdyr/db2rst>`_.
|
||||
|
||||
* Christophe de Vienne wrote a tool to convert from Open/LibreOffice documents
|
||||
to Sphinx: `odt2sphinx <https://pypi.python.org/pypi/odt2sphinx/>`_.
|
||||
to Sphinx: `odt2sphinx <https://pypi.org/project/odt2sphinx/>`_.
|
||||
|
||||
* To convert different markups, `Pandoc <http://pandoc.org/>`_ is
|
||||
* To convert different markups, `Pandoc <https://pandoc.org/>`_ is
|
||||
a very helpful tool.
|
||||
|
||||
|
||||
@@ -56,19 +55,17 @@ See the :ref:`pertinent section in the FAQ list <usingwith>`.
|
||||
Prerequisites
|
||||
-------------
|
||||
|
||||
Sphinx needs at least **Python 2.7** or **Python 3.4** to run, as well as the
|
||||
docutils_ and Jinja2_ libraries. Sphinx should work with docutils version 0.10
|
||||
or some (not broken) SVN trunk snapshot. If you like to have source code
|
||||
highlighting support, you must also install the Pygments_ library.
|
||||
Sphinx needs at least **Python 3.5** to run, as well as the docutils_ and
|
||||
Jinja2_ libraries. Sphinx should work with docutils version 0.12 or some (not
|
||||
broken) SVN trunk snapshot.
|
||||
|
||||
.. _reStructuredText: http://docutils.sourceforge.net/rst.html
|
||||
.. _docutils: http://docutils.sourceforge.net/
|
||||
.. _Jinja2: http://jinja.pocoo.org/
|
||||
.. _Pygments: http://pygments.org/
|
||||
|
||||
|
||||
Usage
|
||||
-----
|
||||
|
||||
See :doc:`tutorial` for an introduction. It also contains links to more
|
||||
advanced sections in this manual for the topics it discusses.
|
||||
See :doc:`/usage/quickstart` for an introduction. It also contains links to
|
||||
more advanced sections in this manual for the topics it discusses.
|
||||
@@ -1,566 +0,0 @@
|
||||
.. default-role:: any
|
||||
|
||||
.. _invocation:
|
||||
|
||||
Invocation of sphinx-quickstart
|
||||
===============================
|
||||
|
||||
The :program:`sphinx-quickstart` script generates a Sphinx documentation set.
|
||||
It is called like this:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ sphinx-quickstart [options] [projectdir]
|
||||
|
||||
where *projectdir* is the Sphinx documentation set directory in which you want
|
||||
to place. If you omit *projectdir*, files are generated into current directory
|
||||
by default.
|
||||
|
||||
The :program:`sphinx-quickstart` script has several options:
|
||||
|
||||
.. program:: sphinx-quickstart
|
||||
|
||||
.. option:: -q, --quiet
|
||||
|
||||
Quiet mode that will skips interactive wizard to specify options.
|
||||
This option requires `-p`, `-a` and `-v` options.
|
||||
|
||||
.. option:: -h, --help, --version
|
||||
|
||||
Display usage summary or Sphinx version.
|
||||
|
||||
|
||||
Structure options
|
||||
-----------------
|
||||
|
||||
.. option:: --sep
|
||||
|
||||
If specified, separate source and build directories.
|
||||
|
||||
.. option:: --dot=DOT
|
||||
|
||||
Inside the root directory, two more directories will be created;
|
||||
"_templates" for custom HTML templates and "_static" for custom stylesheets
|
||||
and other static files. You can enter another prefix (such as ".") to
|
||||
replace the underscore.
|
||||
|
||||
Project basic options
|
||||
---------------------
|
||||
|
||||
.. option:: -p PROJECT, --project=PROJECT
|
||||
|
||||
Project name will be set. (see :confval:`project`).
|
||||
|
||||
.. option:: -a AUTHOR, --author=AUTHOR
|
||||
|
||||
Author names. (see :confval:`copyright`).
|
||||
|
||||
.. option:: -v VERSION
|
||||
|
||||
Version of project. (see :confval:`version`).
|
||||
|
||||
.. option:: -r RELEASE, --release=RELEASE
|
||||
|
||||
Release of project. (see :confval:`release`).
|
||||
|
||||
.. option:: -l LANGUAGE, --language=LANGUAGE
|
||||
|
||||
Document language. (see :confval:`language`).
|
||||
|
||||
.. option:: --suffix=SUFFIX
|
||||
|
||||
Source file suffix. (see :confval:`source_suffix`).
|
||||
|
||||
.. option:: --master=MASTER
|
||||
|
||||
Master document name. (see :confval:`master_doc`).
|
||||
|
||||
.. option:: --epub
|
||||
|
||||
Use epub.
|
||||
|
||||
Extension options
|
||||
-----------------
|
||||
|
||||
.. option:: --ext-autodoc
|
||||
|
||||
Enable `sphinx.ext.autodoc` extension.
|
||||
|
||||
.. option:: --ext-doctest
|
||||
|
||||
Enable `sphinx.ext.doctest` extension.
|
||||
|
||||
.. option:: --ext-intersphinx
|
||||
|
||||
Enable `sphinx.ext.intersphinx` extension.
|
||||
|
||||
.. option:: --ext-todo
|
||||
|
||||
Enable `sphinx.ext.todo` extension.
|
||||
|
||||
.. option:: --ext-coverage
|
||||
|
||||
Enable `sphinx.ext.coverage` extension.
|
||||
|
||||
.. option:: --ext-imgmath
|
||||
|
||||
Enable `sphinx.ext.imgmath` extension.
|
||||
|
||||
.. option:: --ext-mathjax
|
||||
|
||||
Enable `sphinx.ext.mathjax` extension.
|
||||
|
||||
.. option:: --ext-ifconfig
|
||||
|
||||
Enable `sphinx.ext.ifconfig` extension.
|
||||
|
||||
.. option:: --ext-viewcode
|
||||
|
||||
Enable `sphinx.ext.viewcode` extension.
|
||||
|
||||
.. option:: --extensions=EXTENSIONS
|
||||
|
||||
Enable arbitary extensions.
|
||||
|
||||
|
||||
Makefile and Batchfile creation options
|
||||
---------------------------------------
|
||||
|
||||
.. option:: --use-make-mode, --no-use-make-mode
|
||||
|
||||
Makefile/make.bat uses (or not use) make-mode. Default is use.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
make-mode is default.
|
||||
|
||||
.. option:: --makefile, --no-makefile
|
||||
|
||||
Create (or not create) makefile.
|
||||
|
||||
.. option:: --batchfile, --no-batchfile
|
||||
|
||||
Create (or not create) batchfile
|
||||
|
||||
|
||||
.. versionadded:: 1.3
|
||||
Add various options for sphinx-quickstart invocation.
|
||||
|
||||
Project templating
|
||||
------------------
|
||||
|
||||
.. option:: -t, --templatedir=TEMPLATEDIR
|
||||
|
||||
Template directory for template files. You can modify the templates of
|
||||
sphinx project files generated by quickstart. Following Jinja2 template
|
||||
files are allowed:
|
||||
|
||||
* master_doc.rst_t
|
||||
* conf.py_t
|
||||
* Makefile_t
|
||||
* Makefile.new_t
|
||||
* make.bat_t
|
||||
* make.bat.new_t
|
||||
|
||||
In detail, please refer the system template files Sphinx provides.
|
||||
(sphinx/templates/quickstart)
|
||||
|
||||
.. option:: -d NAME=VALUE
|
||||
|
||||
Define a template variable
|
||||
|
||||
.. versionadded:: 1.5
|
||||
Project templating options for sphinx-quickstart
|
||||
|
||||
|
||||
Invocation of sphinx-build
|
||||
==========================
|
||||
|
||||
The :program:`sphinx-build` script builds a Sphinx documentation set. It is
|
||||
called like this:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ sphinx-build [options] sourcedir builddir [filenames]
|
||||
|
||||
where *sourcedir* is the :term:`source directory`, and *builddir* is the
|
||||
directory in which you want to place the built documentation. Most of the time,
|
||||
you don't need to specify any *filenames*.
|
||||
|
||||
The :program:`sphinx-build` script has several options:
|
||||
|
||||
.. program:: sphinx-build
|
||||
|
||||
.. option:: -b buildername
|
||||
|
||||
The most important option: it selects a builder. The most common builders
|
||||
are:
|
||||
|
||||
**html**
|
||||
Build HTML pages. This is the default builder.
|
||||
|
||||
**dirhtml**
|
||||
Build HTML pages, but with a single directory per document. Makes for
|
||||
prettier URLs (no ``.html``) if served from a webserver.
|
||||
|
||||
**singlehtml**
|
||||
Build a single HTML with the whole content.
|
||||
|
||||
**htmlhelp**, **qthelp**, **devhelp**, **epub**
|
||||
Build HTML files with additional information for building a documentation
|
||||
collection in one of these formats.
|
||||
|
||||
**applehelp**
|
||||
Build an Apple Help Book. Requires :program:`hiutil` and
|
||||
:program:`codesign`, which are not Open Source and presently only
|
||||
available on Mac OS X 10.6 and higher.
|
||||
|
||||
**latex**
|
||||
Build LaTeX sources that can be compiled to a PDF document using
|
||||
:program:`pdflatex`.
|
||||
|
||||
**man**
|
||||
Build manual pages in groff format for UNIX systems.
|
||||
|
||||
**texinfo**
|
||||
Build Texinfo files that can be processed into Info files using
|
||||
:program:`makeinfo`.
|
||||
|
||||
**text**
|
||||
Build plain text files.
|
||||
|
||||
**gettext**
|
||||
Build gettext-style message catalogs (``.pot`` files).
|
||||
|
||||
**doctest**
|
||||
Run all doctests in the documentation, if the :mod:`~sphinx.ext.doctest`
|
||||
extension is enabled.
|
||||
|
||||
**linkcheck**
|
||||
Check the integrity of all external links.
|
||||
|
||||
**xml**
|
||||
Build Docutils-native XML files.
|
||||
|
||||
**pseudoxml**
|
||||
Build compact pretty-printed "pseudo-XML" files displaying the
|
||||
internal structure of the intermediate document trees.
|
||||
|
||||
See :ref:`builders` for a list of all builders shipped with Sphinx.
|
||||
Extensions can add their own builders.
|
||||
|
||||
.. option:: -a
|
||||
|
||||
If given, always write all output files. The default is to only write output
|
||||
files for new and changed source files. (This may not apply to all
|
||||
builders.)
|
||||
|
||||
.. option:: -E
|
||||
|
||||
Don't use a saved :term:`environment` (the structure caching all
|
||||
cross-references), but rebuild it completely. The default is to only read
|
||||
and parse source files that are new or have changed since the last run.
|
||||
|
||||
.. option:: -t tag
|
||||
|
||||
Define the tag *tag*. This is relevant for :rst:dir:`only` directives that
|
||||
only include their content if this tag is set.
|
||||
|
||||
.. versionadded:: 0.6
|
||||
|
||||
.. option:: -d path
|
||||
|
||||
Since Sphinx has to read and parse all source files before it can write an
|
||||
output file, the parsed source files are cached as "doctree pickles".
|
||||
Normally, these files are put in a directory called :file:`.doctrees` under
|
||||
the build directory; with this option you can select a different cache
|
||||
directory (the doctrees can be shared between all builders).
|
||||
|
||||
.. option:: -j N
|
||||
|
||||
Distribute the build over *N* processes in parallel, to make building on
|
||||
multiprocessor machines more effective. Note that not all parts and not all
|
||||
builders of Sphinx can be parallelized.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
This option should be considered *experimental*.
|
||||
|
||||
.. option:: -c path
|
||||
|
||||
Don't look for the :file:`conf.py` in the source directory, but use the given
|
||||
configuration directory instead. Note that various other files and paths
|
||||
given by configuration values are expected to be relative to the
|
||||
configuration directory, so they will have to be present at this location
|
||||
too.
|
||||
|
||||
.. versionadded:: 0.3
|
||||
|
||||
.. option:: -C
|
||||
|
||||
Don't look for a configuration file; only take options via the ``-D`` option.
|
||||
|
||||
.. versionadded:: 0.5
|
||||
|
||||
.. option:: -D setting=value
|
||||
|
||||
Override a configuration value set in the :file:`conf.py` file. The value
|
||||
must be a number, string, list or dictionary value.
|
||||
|
||||
For lists, you can separate elements with a comma like this: ``-D
|
||||
html_theme_path=path1,path2``.
|
||||
|
||||
For dictionary values, supply the setting name and key like this:
|
||||
``-D latex_elements.docclass=scrartcl``.
|
||||
|
||||
For boolean values, use ``0`` or ``1`` as the value.
|
||||
|
||||
.. versionchanged:: 0.6
|
||||
The value can now be a dictionary value.
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
The value can now also be a list value.
|
||||
|
||||
.. option:: -A name=value
|
||||
|
||||
Make the *name* assigned to *value* in the HTML templates.
|
||||
|
||||
.. versionadded:: 0.5
|
||||
|
||||
.. option:: -n
|
||||
|
||||
Run in nit-picky mode. Currently, this generates warnings for all missing
|
||||
references. See the config value :confval:`nitpick_ignore` for a way to
|
||||
exclude some references as "known missing".
|
||||
|
||||
.. option:: -N
|
||||
|
||||
Do not emit colored output.
|
||||
|
||||
.. option:: -v
|
||||
|
||||
Increase verbosity (loglevel). This option can be given up to three times
|
||||
to get more debug logging output. It implies :option:`-T`.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
.. option:: -q
|
||||
|
||||
Do not output anything on standard output, only write warnings and errors to
|
||||
standard error.
|
||||
|
||||
.. option:: -Q
|
||||
|
||||
Do not output anything on standard output, also suppress warnings. Only
|
||||
errors are written to standard error.
|
||||
|
||||
.. option:: -w file
|
||||
|
||||
Write warnings (and errors) to the given file, in addition to standard error.
|
||||
|
||||
.. option:: -W
|
||||
|
||||
Turn warnings into errors. This means that the build stops at the first
|
||||
warning and ``sphinx-build`` exits with exit status 1.
|
||||
|
||||
.. option:: -T
|
||||
|
||||
Display the full traceback when an unhandled exception occurs. Otherwise,
|
||||
only a summary is displayed and the traceback information is saved to a file
|
||||
for further analysis.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
.. option:: -P
|
||||
|
||||
(Useful for debugging only.) Run the Python debugger, :mod:`pdb`, if an
|
||||
unhandled exception occurs while building.
|
||||
|
||||
.. option:: -h, --help, --version
|
||||
|
||||
Display usage summary or Sphinx version.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
You can also give one or more filenames on the command line after the source and
|
||||
build directories. Sphinx will then try to build only these output files (and
|
||||
their dependencies).
|
||||
|
||||
Environment variables
|
||||
---------------------
|
||||
|
||||
The :program:`sphinx-build` refers following environment variables:
|
||||
|
||||
.. describe:: MAKE
|
||||
|
||||
A path to make command. A command name is also allowed.
|
||||
:program:`sphinx-build` uses it to invoke sub-build process on make-mode.
|
||||
|
||||
Makefile options
|
||||
----------------
|
||||
|
||||
The :file:`Makefile` and :file:`make.bat` files created by
|
||||
:program:`sphinx-quickstart` usually run :program:`sphinx-build` only with the
|
||||
:option:`-b` and :option:`-d` options. However, they support the following
|
||||
variables to customize behavior:
|
||||
|
||||
.. describe:: PAPER
|
||||
|
||||
The value for '"papersize"` key of :confval:`latex_elements`.
|
||||
|
||||
.. describe:: SPHINXBUILD
|
||||
|
||||
The command to use instead of ``sphinx-build``.
|
||||
|
||||
.. describe:: BUILDDIR
|
||||
|
||||
The build directory to use instead of the one chosen in
|
||||
:program:`sphinx-quickstart`.
|
||||
|
||||
.. describe:: SPHINXOPTS
|
||||
|
||||
Additional options for :program:`sphinx-build`.
|
||||
|
||||
.. _when-deprecation-warnings-are-displayed:
|
||||
|
||||
Deprecation Warnings
|
||||
--------------------
|
||||
|
||||
If any deprecation warning like ``RemovedInSphinxXXXWarning`` are displayed
|
||||
when building a user's document, some Sphinx extension is using deprecated
|
||||
features. In that case, please report it to author of the extension.
|
||||
|
||||
To disable the deprecation warnings, please set ``PYTHONWARNINGS=`` environment
|
||||
variable to your environment. For example:
|
||||
|
||||
* ``PYTHONWARNINGS= make html`` (Linux/Mac)
|
||||
* ``export PYTHONWARNINGS=`` and do ``make html`` (Linux/Mac)
|
||||
* ``set PYTHONWARNINGS=`` and do ``make html`` (Windows)
|
||||
* modify your Makefile/make.bat and set the environment variable
|
||||
|
||||
|
||||
.. _invocation-apidoc:
|
||||
|
||||
Invocation of sphinx-apidoc
|
||||
===========================
|
||||
|
||||
The :program:`sphinx-apidoc` generates completely automatic API documentation
|
||||
for a Python package. It is called like this:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ sphinx-apidoc [options] -o outputdir packagedir [pathnames]
|
||||
|
||||
where *packagedir* is the path to the package to document, and *outputdir* is
|
||||
the directory where the generated sources are placed. Any *pathnames* given
|
||||
are paths to be excluded ignored during generation.
|
||||
|
||||
.. warning::
|
||||
|
||||
``sphinx-apidoc`` generates reST files that use :mod:`sphinx.ext.autodoc` to
|
||||
document all found modules. If any modules have side effects on import,
|
||||
these will be executed by ``autodoc`` when ``sphinx-build`` is run.
|
||||
|
||||
If you document scripts (as opposed to library modules), make sure their main
|
||||
routine is protected by a ``if __name__ == '__main__'`` condition.
|
||||
|
||||
|
||||
The :program:`sphinx-apidoc` script has several options:
|
||||
|
||||
.. program:: sphinx-apidoc
|
||||
|
||||
.. option:: -o outputdir
|
||||
|
||||
Gives the directory in which to place the generated output.
|
||||
|
||||
.. option:: -f, --force
|
||||
|
||||
Normally, sphinx-apidoc does not overwrite any files. Use this option to
|
||||
force the overwrite of all files that it generates.
|
||||
|
||||
.. option:: -n, --dry-run
|
||||
|
||||
With this option given, no files will be written at all.
|
||||
|
||||
.. option:: -e, --separate
|
||||
|
||||
Put documentation for each module on its own page.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
.. option:: -P, --private
|
||||
|
||||
Include "_private" modules.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
.. option:: -s suffix
|
||||
|
||||
This option selects the file name suffix of output files. By default, this
|
||||
is ``rst``.
|
||||
|
||||
.. option:: -d maxdepth
|
||||
|
||||
This sets the maximum depth of the table of contents, if one is generated.
|
||||
|
||||
.. option:: -l, --follow-links
|
||||
|
||||
This option makes sphinx-apidoc follow symbolic links when recursing the
|
||||
filesystem to discover packages and modules. You may need it if you want
|
||||
to generate documentation from a source directory managed by
|
||||
`collective.recipe.omelette
|
||||
<https://pypi.python.org/pypi/collective.recipe.omelette/>`_.
|
||||
By default, symbolic links are skipped.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
.. option:: -T, --no-toc
|
||||
|
||||
This prevents the generation of a table-of-contents file ``modules.rst``.
|
||||
This has no effect when :option:`--full` is given.
|
||||
|
||||
.. option:: -E, --no-headings
|
||||
|
||||
Don't create headings for the module/package packages (e.g. when the
|
||||
docstrings already contain them).
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
.. option:: -F, --full
|
||||
|
||||
This option makes sphinx-apidoc create a full Sphinx project, using the same
|
||||
mechanism as :program:`sphinx-quickstart`. Most configuration values are set
|
||||
to default values, but you can influence the most important ones using the
|
||||
following options.
|
||||
|
||||
.. option:: --implicit-namespaces
|
||||
|
||||
By default sphinx-apidoc processes sys.path searching for modules only.
|
||||
Python 3.3 introduced :pep:`420` implicit namespaces that allow module path
|
||||
structures such as ``foo/bar/module.py`` or ``foo/bar/baz/__init__.py``
|
||||
(notice that ``bar`` and ``foo`` are namespaces, not modules).
|
||||
|
||||
Specifying this option interprets paths recursively according to PEP-0420.
|
||||
|
||||
.. option:: -M
|
||||
|
||||
This option makes sphinx-apidoc put module documentation before submodule
|
||||
documentation.
|
||||
|
||||
.. option:: -a
|
||||
|
||||
Append module_path to sys.path.
|
||||
|
||||
.. option:: -H project
|
||||
|
||||
Sets the project name to put in generated files (see :confval:`project`).
|
||||
|
||||
.. option:: -A author
|
||||
|
||||
Sets the author name(s) to put in generated files (see :confval:`copyright`).
|
||||
|
||||
.. option:: -V version
|
||||
|
||||
Sets the project version to put in generated files (see :confval:`version`).
|
||||
|
||||
.. option:: -R release
|
||||
|
||||
Sets the project release to put in generated files (see :confval:`release`).
|
||||
+76
-57
@@ -1,4 +1,4 @@
|
||||
.. highlightlang:: python
|
||||
.. highlight:: python
|
||||
|
||||
.. _latex:
|
||||
|
||||
@@ -8,8 +8,8 @@ LaTeX customization
|
||||
.. module:: latex
|
||||
:synopsis: LaTeX specifics.
|
||||
|
||||
The *latex* target does not benefit from pre-prepared themes like the
|
||||
*html* target does (see :doc:`theming`).
|
||||
For details of the LaTeX/PDF builder command line invocation, refer to
|
||||
:py:class:`~sphinx.builders.latex.LaTeXBuilder`.
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
@@ -29,12 +29,15 @@ The *latex* target does not benefit from pre-prepared themes like the
|
||||
cautionBgColor={named}{LightCyan}}
|
||||
\relax
|
||||
|
||||
.. _latex-basic:
|
||||
|
||||
Basic customization
|
||||
-------------------
|
||||
|
||||
It is achieved via usage of the
|
||||
:ref:`latex-options` as described in :doc:`config`. For example::
|
||||
The *latex* target does not benefit from prepared themes.
|
||||
|
||||
Basic customization is obtained via usage of the :ref:`latex-options`. For
|
||||
example::
|
||||
|
||||
# inside conf.py
|
||||
latex_engine = 'xelatex'
|
||||
@@ -61,28 +64,31 @@ It is achieved via usage of the
|
||||
.. highlight:: latex
|
||||
|
||||
If the size of the ``'preamble'`` contents becomes inconvenient, one may move
|
||||
all needed macros into some file :file:`mystyle.tex` of the project source
|
||||
all needed macros into some file :file:`mystyle.tex.txt` of the project source
|
||||
repertory, and get LaTeX to import it at run time::
|
||||
|
||||
'preamble': r'\input{mystyle.tex}',
|
||||
'preamble': r'\input{mystyle.tex.txt}',
|
||||
# or, if the \ProvidesPackage LaTeX macro is used in a file mystyle.sty
|
||||
'preamble': r'\usepackage{mystyle}',
|
||||
|
||||
It is needed to set appropriately :confval:`latex_additional_files`, for
|
||||
It is then needed to set appropriately :confval:`latex_additional_files`, for
|
||||
example::
|
||||
|
||||
latex_additional_files = ["mystyle.tex"]
|
||||
latex_additional_files = ["mystyle.sty"]
|
||||
|
||||
.. _latexsphinxsetup:
|
||||
|
||||
The LaTeX style file options
|
||||
----------------------------
|
||||
|
||||
Additional customization is possible via LaTeX options of the Sphinx style
|
||||
file.
|
||||
|
||||
The sphinxsetup interface
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The ``'sphinxsetup'`` key of :confval:`latex_elements` provides a convenient
|
||||
interface to the package options of the Sphinx style file::
|
||||
interface::
|
||||
|
||||
latex_elements = {
|
||||
'sphinxsetup': 'key1=value1, key2=value2, ...',
|
||||
@@ -102,40 +108,39 @@ inside the document preamble, like this::
|
||||
|
||||
.. versionadded:: 1.5
|
||||
|
||||
It is possible to insert further uses of the ``\sphinxsetup`` LaTeX macro
|
||||
directly into the body of the document, via the help of the :rst:dir:`raw`
|
||||
directive. This is what is done for this documentation, for local styling
|
||||
of this chapter in the PDF output::
|
||||
.. hint::
|
||||
|
||||
.. raw:: latex
|
||||
It is possible to insert further uses of the ``\sphinxsetup`` LaTeX macro
|
||||
directly into the body of the document, via the help of the :rst:dir:`raw`
|
||||
directive. Here is how this present chapter in PDF is styled::
|
||||
|
||||
\begingroup
|
||||
\sphinxsetup{%
|
||||
verbatimwithframe=false,
|
||||
VerbatimColor={named}{OldLace},
|
||||
TitleColor={named}{DarkGoldenrod},
|
||||
hintBorderColor={named}{LightCoral},
|
||||
attentionborder=3pt,
|
||||
attentionBorderColor={named}{Crimson},
|
||||
attentionBgColor={named}{FloralWhite},
|
||||
noteborder=2pt,
|
||||
noteBorderColor={named}{Olive},
|
||||
cautionborder=3pt,
|
||||
cautionBorderColor={named}{Cyan},
|
||||
cautionBgColor={named}{LightCyan}}
|
||||
.. raw:: latex
|
||||
|
||||
at the start of the chapter and::
|
||||
\begingroup
|
||||
\sphinxsetup{%
|
||||
verbatimwithframe=false,
|
||||
VerbatimColor={named}{OldLace},
|
||||
TitleColor={named}{DarkGoldenrod},
|
||||
hintBorderColor={named}{LightCoral},
|
||||
attentionborder=3pt,
|
||||
attentionBorderColor={named}{Crimson},
|
||||
attentionBgColor={named}{FloralWhite},
|
||||
noteborder=2pt,
|
||||
noteBorderColor={named}{Olive},
|
||||
cautionborder=3pt,
|
||||
cautionBorderColor={named}{Cyan},
|
||||
cautionBgColor={named}{LightCyan}}
|
||||
|
||||
.. raw:: latex
|
||||
at the start of the chapter and::
|
||||
|
||||
\endgroup
|
||||
.. raw:: latex
|
||||
|
||||
at its end.
|
||||
\endgroup
|
||||
|
||||
.. note::
|
||||
at its end.
|
||||
|
||||
The colors above are made available via the ``svgnames`` option of
|
||||
the "xcolor" package::
|
||||
The colors used in the above are provided by the ``svgnames`` option of the
|
||||
"xcolor" package::
|
||||
|
||||
latex_elements = {
|
||||
'passoptionstopackages': r'\PassOptionsToPackage{svgnames}{xcolor}',
|
||||
@@ -189,14 +194,25 @@ The available styling options
|
||||
default ``true``. Tells whether long lines in :rst:dir:`code-block`\ 's
|
||||
contents should wrap.
|
||||
|
||||
``literalblockcappos``
|
||||
default ``t`` for "top". Decides the caption position. Alternative is
|
||||
``b`` ("bottom").
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
``verbatimhintsturnover``
|
||||
default ``false``. If ``true``, code-blocks display "continued on next
|
||||
default ``true``. If ``true``, code-blocks display "continued on next
|
||||
page", "continued from previous page" hints in case of pagebreaks.
|
||||
|
||||
.. versionadded:: 1.6.3
|
||||
the default will change to ``true`` at 1.7 and horizontal positioning
|
||||
of continuation hints (currently right aligned only) will be
|
||||
customizable.
|
||||
.. versionchanged:: 1.7
|
||||
the default changed from ``false`` to ``true``.
|
||||
|
||||
``verbatimcontinuedalign``, ``verbatimcontinuesalign``
|
||||
default ``c``. Horizontal position relative to the framed contents:
|
||||
either ``l`` (left aligned), ``r`` (right aligned) or ``c`` (centered).
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
``parsedliteralwraps``
|
||||
default ``true``. Tells whether long lines in :dudir:`parsed-literal`\ 's
|
||||
@@ -255,6 +271,16 @@ The available styling options
|
||||
``VerbatimBorderColor``
|
||||
default ``{rgb}{0,0,0}``. The frame color, defaults to black.
|
||||
|
||||
``VerbatimHighlightColor``
|
||||
default ``{rgb}{0.878,1,1}``. The color for highlighted lines.
|
||||
|
||||
.. versionadded:: 1.6.6
|
||||
|
||||
.. note::
|
||||
|
||||
Starting with this colour key, and for all others coming next, the actual
|
||||
names declared to "color" or "xcolor" are prefixed with "sphinx".
|
||||
|
||||
``verbatimsep``
|
||||
default ``\fboxsep``. The separation between code lines and the frame.
|
||||
|
||||
@@ -276,11 +302,6 @@ The available styling options
|
||||
default ``{rgb}{0,0,0}`` (black). The colour for the two horizontal rules
|
||||
used by Sphinx in LaTeX for styling a :dudir:`note` type admonition.
|
||||
|
||||
.. note::
|
||||
|
||||
The actual colour names declared to "color" or "xcolor" are prefixed with
|
||||
"sphinx".
|
||||
|
||||
``noteborder``, ``hintborder``, ``importantborder``, ``tipborder``
|
||||
default ``0.5pt``. The width of the two horizontal rules.
|
||||
|
||||
@@ -356,10 +377,9 @@ Macros
|
||||
with LaTeX packages.
|
||||
- more text styling: ``\sphinxstyle<bar>`` with ``<bar>`` one of
|
||||
``indexentry``, ``indexextra``, ``indexpageref``, ``topictitle``,
|
||||
``sidebartitle``, ``othertitle``, ``sidebarsubtitle``,
|
||||
``theadfamily``, ``emphasis``, ``literalemphasis``, ``strong``,
|
||||
``literalstrong``, ``abbreviation``, ``literalintitle``, ``codecontinued``,
|
||||
``codecontinues``.
|
||||
``sidebartitle``, ``othertitle``, ``sidebarsubtitle``, ``theadfamily``,
|
||||
``emphasis``, ``literalemphasis``, ``strong``, ``literalstrong``,
|
||||
``abbreviation``, ``literalintitle``, ``codecontinued``, ``codecontinues``
|
||||
|
||||
.. versionadded:: 1.5
|
||||
these macros were formerly hard-coded as non customizable ``\texttt``,
|
||||
@@ -369,13 +389,6 @@ Macros
|
||||
multiple paragraphs in header cells of tables.
|
||||
.. versionadded:: 1.6.3
|
||||
``\sphinxstylecodecontinued`` and ``\sphinxstylecodecontinues``.
|
||||
- by default the Sphinx style file ``sphinx.sty`` executes the command
|
||||
``\fvset{fontsize=\small}`` as part of its configuration of
|
||||
``fancyvrb.sty``. This may be overriden for example via
|
||||
``\fvset{fontsize=auto}`` which will let code listings use the ambient font
|
||||
size. Refer to ``fancyvrb.sty``'s documentation for further keys.
|
||||
|
||||
.. versionadded:: 1.5
|
||||
- the table of contents is typeset via ``\sphinxtableofcontents`` which is a
|
||||
wrapper (whose definition can be found in :file:`sphinxhowto.cls` or in
|
||||
:file:`sphinxmanual.cls`) of standard ``\tableofcontents``.
|
||||
@@ -384,6 +397,8 @@ Macros
|
||||
formerly, the meaning of ``\tableofcontents`` was modified by Sphinx.
|
||||
- the ``\maketitle`` command is redefined by the class files
|
||||
:file:`sphinxmanual.cls` and :file:`sphinxhowto.cls`.
|
||||
- the citation reference is typeset via ``\sphinxcite`` which is a wrapper
|
||||
of standard ``\cite``.
|
||||
|
||||
Environments
|
||||
~~~~~~~~~~~~
|
||||
@@ -430,6 +445,11 @@ Environments
|
||||
.. versionadded:: 1.5
|
||||
options ``verbatimwithframe``, ``verbatimwrapslines``,
|
||||
``verbatimsep``, ``verbatimborder``.
|
||||
.. versionadded:: 1.6.6
|
||||
support for ``:emphasize-lines:`` option
|
||||
.. versionadded:: 1.6.6
|
||||
easier customizability of the formatting via exposed to user LaTeX macros
|
||||
such as ``\sphinxVerbatimHighlightLine``.
|
||||
- the bibliography uses ``sphinxthebibliography`` and the Python Module index
|
||||
as well as the general index both use ``sphinxtheindex``; these environments
|
||||
are wrappers of the ``thebibliography`` and respectively ``theindex``
|
||||
@@ -451,7 +471,6 @@ Miscellany
|
||||
.. versionchanged:: 1.5
|
||||
formerly, use of *fncychap* with other styles than ``Bjarne`` was
|
||||
dysfunctional.
|
||||
- check file :file:`sphinx.sty` for more...
|
||||
|
||||
.. hint::
|
||||
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@
|
||||
REM Command file for Sphinx documentation
|
||||
|
||||
if "%SPHINXBUILD%" == "" (
|
||||
set SPHINXBUILD=python ../sphinx-build.py
|
||||
set SPHINXBUILD=python ../sphinx/cmd/build.py
|
||||
)
|
||||
set SOURCEDIR=.
|
||||
set BUILDDIR=_build
|
||||
|
||||
@@ -0,0 +1,22 @@
|
||||
Man Pages
|
||||
=========
|
||||
|
||||
These are the applications provided as part of Sphinx.
|
||||
|
||||
Core Applications
|
||||
-----------------
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 3
|
||||
|
||||
sphinx-quickstart
|
||||
sphinx-build
|
||||
|
||||
Additional Applications
|
||||
-----------------------
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 3
|
||||
|
||||
sphinx-apidoc
|
||||
sphinx-autogen
|
||||
+110
-38
@@ -1,23 +1,24 @@
|
||||
:orphan:
|
||||
|
||||
sphinx-apidoc manual page
|
||||
=========================
|
||||
sphinx-apidoc
|
||||
=============
|
||||
|
||||
Synopsis
|
||||
--------
|
||||
|
||||
**sphinx-apidoc** [*options*] -o <*outputdir*> <*sourcedir*> [*pathnames* ...]
|
||||
|
||||
**sphinx-apidoc** [*OPTIONS*] -o <*OUTPUT_PATH*> <*MODULE_PATH*> [*EXCLUDE_PATTERN*, ...]
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
:program:`sphinx-apidoc` is a tool for automatic generation of Sphinx sources
|
||||
that, using the autodoc extension, document a whole package in the style of
|
||||
other automatic API documentation tools.
|
||||
that, using the :rst:dir:`autodoc` extension, document a whole package in the
|
||||
style of other automatic API documentation tools.
|
||||
|
||||
*sourcedir* must point to a Python package. Any *pathnames* given are paths to
|
||||
be excluded from the generation.
|
||||
*MODULE_PATH* is the path to a Python package to document, and *OUTPUT_PATH* is
|
||||
the directory where the generated sources are placed. Any *EXCLUDE_PATTERN*\s
|
||||
given are `fnmatch-style`_ file and/or directory patterns that will be excluded
|
||||
from generation.
|
||||
|
||||
.. _fnmatch-style: https://docs.python.org/3/library/fnmatch.html
|
||||
|
||||
.. warning::
|
||||
|
||||
@@ -28,42 +29,113 @@ be excluded from the generation.
|
||||
If you document scripts (as opposed to library modules), make sure their main
|
||||
routine is protected by a ``if __name__ == '__main__'`` condition.
|
||||
|
||||
|
||||
Options
|
||||
-------
|
||||
|
||||
-o <outputdir> Directory to place the output files. If it does not exist,
|
||||
it is created.
|
||||
-f, --force Usually, apidoc does not overwrite files, unless this option
|
||||
is given.
|
||||
-l, --follow-links Follow symbolic links.
|
||||
-n, --dry-run If given, apidoc does not create any files.
|
||||
-s <suffix> Suffix for the source files generated, default is ``rst``.
|
||||
-d <maxdepth> Maximum depth for the generated table of contents file.
|
||||
-T, --no-toc Do not create a table of contents file.
|
||||
-F, --full If given, a full Sphinx project is generated (``conf.py``,
|
||||
``Makefile`` etc.) using sphinx-quickstart.
|
||||
-e, --separate Put each module file in its own page.
|
||||
-E, --no-headings Don't create headings for the modules/packages
|
||||
-P, --private Include "_private" modules
|
||||
.. program:: sphinx-apidoc
|
||||
|
||||
These options are used with ``-F``:
|
||||
.. option:: -o <OUTPUT_PATH>
|
||||
|
||||
-a Append module_path to sys.path.
|
||||
-H <project> Project name to put into the configuration.
|
||||
-A <author> Author name(s) to put into the configuration.
|
||||
-V <version> Project version.
|
||||
-R <release> Project release.
|
||||
Directory to place the output files. If it does not exist, it is created.
|
||||
|
||||
.. option:: -f, --force
|
||||
|
||||
Force overwritting of any existing generated files.
|
||||
|
||||
.. option:: -l, --follow-links
|
||||
|
||||
Follow symbolic links.
|
||||
|
||||
.. option:: -n, --dry-run
|
||||
|
||||
Do not create any files.
|
||||
|
||||
.. option:: -s <suffix>
|
||||
|
||||
Suffix for the source files generated. Defaults to ``rst``.
|
||||
|
||||
.. option:: -d <MAXDEPTH>
|
||||
|
||||
Maximum depth for the generated table of contents file.
|
||||
|
||||
.. option:: --tocfile
|
||||
|
||||
Filename for a table of contents file. Defaults to ``modules``.
|
||||
|
||||
.. option:: -T, --no-toc
|
||||
|
||||
Do not create a table of contents file. Ignored when :option:`--full` is
|
||||
provided.
|
||||
|
||||
.. option:: -F, --full
|
||||
|
||||
Generate a full Sphinx project (``conf.py``, ``Makefile`` etc.) using
|
||||
the same mechanism as :program:`sphinx-quickstart`.
|
||||
|
||||
.. option:: -e, --separate
|
||||
|
||||
Put documentation for each module on its own page.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
.. option:: -E, --no-headings
|
||||
|
||||
Do not create headings for the modules/packages. This is useful, for
|
||||
example, when docstrings already contain headings.
|
||||
|
||||
.. option:: -P, --private
|
||||
|
||||
Include "_private" modules.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
.. option:: --implicit-namespaces
|
||||
|
||||
By default sphinx-apidoc processes sys.path searching for modules only.
|
||||
Python 3.3 introduced :pep:`420` implicit namespaces that allow module path
|
||||
structures such as ``foo/bar/module.py`` or ``foo/bar/baz/__init__.py``
|
||||
(notice that ``bar`` and ``foo`` are namespaces, not modules).
|
||||
|
||||
Interpret paths recursively according to PEP-0420.
|
||||
|
||||
.. option:: -M, --module-first
|
||||
|
||||
Put module documentation before submodule documentation.
|
||||
|
||||
These options are used when :option:`--full` is specified:
|
||||
|
||||
.. option:: -a
|
||||
|
||||
Append module_path to sys.path.
|
||||
|
||||
.. option:: -H <project>
|
||||
|
||||
Sets the project name to put in generated files (see :confval:`project`).
|
||||
|
||||
.. option:: -A <author>
|
||||
|
||||
Sets the author name(s) to put in generated files (see
|
||||
:confval:`copyright`).
|
||||
|
||||
.. option:: -V <version>
|
||||
|
||||
Sets the project version to put in generated files (see :confval:`version`).
|
||||
|
||||
.. option:: -R <release>
|
||||
|
||||
Sets the project release to put in generated files (see :confval:`release`).
|
||||
|
||||
Environment
|
||||
-----------
|
||||
|
||||
.. envvar:: SPHINX_APIDOC_OPTIONS
|
||||
|
||||
A comma-separated list of option to append to generated ``automodule``
|
||||
directives. Defaults to ``members,undoc-members,show-inheritance``.
|
||||
|
||||
See also
|
||||
--------
|
||||
|
||||
:manpage:`sphinx-build(1)`
|
||||
:manpage:`sphinx-build(1)`, :manpage:`sphinx-autogen(1)`
|
||||
|
||||
|
||||
Author
|
||||
------
|
||||
|
||||
Etienne Desautels, <etienne.desautels@gmail.com>, Georg Brandl
|
||||
<georg@python.org> et al.
|
||||
.. _fnmatch: https://docs.python.org/3/library/fnmatch.html
|
||||
@@ -0,0 +1,93 @@
|
||||
sphinx-autogen
|
||||
==============
|
||||
|
||||
Synopsis
|
||||
--------
|
||||
|
||||
**sphinx-autogen** [*options*] <sourcefile> ...
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
:program:`sphinx-autogen` is a tool for automatic generation of Sphinx sources
|
||||
that, using the :rst:dir:`autodoc` extension, document items included in
|
||||
:rst:dir:`autosummary` listing(s).
|
||||
|
||||
*sourcefile* is the path to one or more reStructuredText documents containing
|
||||
:rst:dir:`autosummary` entries with the ``:toctree::`` option set. *sourcefile*
|
||||
can be an :py:mod:`fnmatch`-style pattern.
|
||||
|
||||
Options
|
||||
-------
|
||||
|
||||
.. program:: sphinx-autogen
|
||||
|
||||
.. option:: -o <outputdir>
|
||||
|
||||
Directory to place the output file. If it does not exist, it is created.
|
||||
Defaults to the value passed to the ``:toctree:`` option.
|
||||
|
||||
.. option:: -s <suffix>, --suffix <suffix>
|
||||
|
||||
Default suffix to use for generated files. Defaults to ``rst``.
|
||||
|
||||
.. option:: -t <templates>, --templates <templates>
|
||||
|
||||
Custom template directory. Defaults to ``None``.
|
||||
|
||||
.. option:: -i, --imported-members
|
||||
|
||||
Document imported members.
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
Given the following directory structure::
|
||||
|
||||
docs
|
||||
├── index.rst
|
||||
└── ...
|
||||
foobar
|
||||
├── foo
|
||||
│ └── __init__.py
|
||||
└── bar
|
||||
├── __init__.py
|
||||
└── baz
|
||||
└── __init__.py
|
||||
|
||||
and assuming ``docs/index.rst`` contained the following:
|
||||
|
||||
.. code-block:: rst
|
||||
|
||||
Modules
|
||||
=======
|
||||
|
||||
.. autosummary::
|
||||
:toctree: modules
|
||||
|
||||
foobar.foo
|
||||
foobar.bar
|
||||
foobar.bar.baz
|
||||
|
||||
If you run the following:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ PYTHONPATH=. sphinx-autodoc doc/index.rst
|
||||
|
||||
then the following stub files will be created in ``docs``::
|
||||
|
||||
docs
|
||||
├── index.rst
|
||||
└── modules
|
||||
├── foobar.bar.rst
|
||||
├── foobar.bar.baz.rst
|
||||
└── foobar.foo.rst
|
||||
|
||||
and each of those files will contain a :rst:dir:`autodoc` directive and some
|
||||
other information.
|
||||
|
||||
See also
|
||||
--------
|
||||
|
||||
:manpage:`sphinx-build(1)`, :manpage:`sphinx-apidoc(1)`
|
||||
+299
-104
@@ -1,132 +1,327 @@
|
||||
:orphan:
|
||||
|
||||
sphinx-build manual page
|
||||
========================
|
||||
sphinx-build
|
||||
============
|
||||
|
||||
Synopsis
|
||||
--------
|
||||
|
||||
**sphinx-build** [*options*] <*sourcedir*> <*outdir*> [*filenames* ...]
|
||||
|
||||
**sphinx-build** [*options*] <*sourcedir*> <*outputdir*> [*filenames* ...]
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
:program:`sphinx-build` generates documentation from the files in
|
||||
``<sourcedir>`` and places it in the ``<outdir>``.
|
||||
``<sourcedir>`` and places it in the ``<outputdir>``.
|
||||
|
||||
:program:`sphinx-build` looks for ``<sourcedir>/conf.py`` for the configuration
|
||||
settings. :manpage:`sphinx-quickstart(1)` may be used to generate template
|
||||
files, including ``conf.py``.
|
||||
|
||||
:program:`sphinx-build` can create documentation in different formats. A format
|
||||
is selected by specifying the builder name on the command line; it defaults to
|
||||
HTML. Builders can also perform other tasks related to documentation
|
||||
processing.
|
||||
:program:`sphinx-build` can create documentation in different formats. A
|
||||
format is selected by specifying the builder name on the command line; it
|
||||
defaults to HTML. Builders can also perform other tasks related to
|
||||
documentation processing.
|
||||
|
||||
By default, everything that is outdated is built. Output only for selected
|
||||
files can be built by specifying individual filenames.
|
||||
|
||||
List of available builders:
|
||||
|
||||
html
|
||||
HTML file generation. This is the default builder.
|
||||
|
||||
dirhtml
|
||||
HTML file generation with every HTML file named "index.html" in a separate
|
||||
directory.
|
||||
|
||||
singlehtml
|
||||
HTML file generation with all content in a single HTML file.
|
||||
|
||||
htmlhelp
|
||||
Generates files for CHM (compiled help files) generation.
|
||||
|
||||
qthelp
|
||||
Generates files for Qt help collection generation.
|
||||
|
||||
devhelp
|
||||
Generates files for the GNOME Devhelp help viewer.
|
||||
|
||||
latex
|
||||
Generates LaTeX output that can be compiled to a PDF document.
|
||||
|
||||
man
|
||||
Generates manual pages.
|
||||
|
||||
texinfo
|
||||
Generates Texinfo output that can be processed by :program:`makeinfo` to
|
||||
generate an Info document.
|
||||
|
||||
epub
|
||||
Generates an ePub e-book version of the HTML output.
|
||||
|
||||
text
|
||||
Generates a plain-text version of the documentation.
|
||||
|
||||
gettext
|
||||
Generates Gettext message catalogs for content translation.
|
||||
|
||||
changes
|
||||
Generates HTML files listing changed/added/deprecated items for
|
||||
the current version of the documented project.
|
||||
|
||||
linkcheck
|
||||
Checks the integrity of all external links in the source.
|
||||
|
||||
pickle / json
|
||||
Generates serialized HTML files for use in web applications.
|
||||
|
||||
xml
|
||||
Generates Docutils-native XML files.
|
||||
|
||||
pseudoxml
|
||||
Generates compact pretty-printed "pseudo-XML" files displaying the
|
||||
internal structure of the intermediate document trees.
|
||||
|
||||
For a list of available options, refer to :option:`sphinx-build -b`.
|
||||
|
||||
Options
|
||||
-------
|
||||
|
||||
-b <builder> Builder to use; defaults to html. See the full list
|
||||
of builders above.
|
||||
-a Generate output for all files; without this option only
|
||||
output for new and changed files is generated.
|
||||
-E Ignore cached files, forces to re-read all source files
|
||||
from disk.
|
||||
-d <path> Path to cached files; defaults to <outdir>/.doctrees.
|
||||
-j <N> Build in parallel with N processes where possible.
|
||||
-c <path> Locate the conf.py file in the specified path instead of
|
||||
<sourcedir>.
|
||||
-C Specify that no conf.py file at all is to be used.
|
||||
Configuration can only be set with the -D option.
|
||||
-D <setting=value> Override a setting from the configuration file.
|
||||
-t <tag> Define *tag* for use in "only" blocks.
|
||||
-A <name=value> Pass a value into the HTML templates (only for HTML
|
||||
builders).
|
||||
-n Run in nit-picky mode, warn about all missing references.
|
||||
-v Increase verbosity (can be repeated).
|
||||
-N Prevent colored output.
|
||||
-q Quiet operation, just print warnings and errors on stderr.
|
||||
-Q Very quiet operation, don't print anything except for
|
||||
errors.
|
||||
-w <file> Write warnings and errors into the given file, in addition
|
||||
to stderr.
|
||||
-W Turn warnings into errors.
|
||||
-T Show full traceback on exception.
|
||||
-P Run Pdb on exception.
|
||||
.. program:: sphinx-build
|
||||
|
||||
.. option:: -b buildername
|
||||
|
||||
The most important option: it selects a builder. The most common builders
|
||||
are:
|
||||
|
||||
**html**
|
||||
Build HTML pages. This is the default builder.
|
||||
|
||||
**dirhtml**
|
||||
Build HTML pages, but with a single directory per document. Makes for
|
||||
prettier URLs (no ``.html``) if served from a webserver.
|
||||
|
||||
**singlehtml**
|
||||
Build a single HTML with the whole content.
|
||||
|
||||
**htmlhelp**, **qthelp**, **devhelp**, **epub**
|
||||
Build HTML files with additional information for building a documentation
|
||||
collection in one of these formats.
|
||||
|
||||
**applehelp**
|
||||
Build an Apple Help Book. Requires :program:`hiutil` and
|
||||
:program:`codesign`, which are not Open Source and presently only
|
||||
available on Mac OS X 10.6 and higher.
|
||||
|
||||
**latex**
|
||||
Build LaTeX sources that can be compiled to a PDF document using
|
||||
:program:`pdflatex`.
|
||||
|
||||
**man**
|
||||
Build manual pages in groff format for UNIX systems.
|
||||
|
||||
**texinfo**
|
||||
Build Texinfo files that can be processed into Info files using
|
||||
:program:`makeinfo`.
|
||||
|
||||
**text**
|
||||
Build plain text files.
|
||||
|
||||
**gettext**
|
||||
Build gettext-style message catalogs (``.pot`` files).
|
||||
|
||||
**doctest**
|
||||
Run all doctests in the documentation, if the :mod:`~sphinx.ext.doctest`
|
||||
extension is enabled.
|
||||
|
||||
**linkcheck**
|
||||
Check the integrity of all external links.
|
||||
|
||||
**xml**
|
||||
Build Docutils-native XML files.
|
||||
|
||||
**pseudoxml**
|
||||
Build compact pretty-printed "pseudo-XML" files displaying the
|
||||
internal structure of the intermediate document trees.
|
||||
|
||||
See :doc:`/usage/builders/index` for a list of all builders shipped with
|
||||
Sphinx. Extensions can add their own builders.
|
||||
|
||||
.. _make_mode:
|
||||
|
||||
.. option:: -M buildername
|
||||
|
||||
Alternative to :option:`-b`. Uses the Sphinx :program:`make_mode` module,
|
||||
which provides the same build functionality as a default :ref:`Makefile or
|
||||
Make.bat <makefile_options>`. In addition to all Sphinx
|
||||
:doc:`/usage/builders/index`, the following build pipelines are available:
|
||||
|
||||
**latexpdf**
|
||||
Build LaTeX files and run them through :program:`pdflatex`, or as per
|
||||
:confval:`latex_engine` setting.
|
||||
If :confval:`language` is set to ``'ja'``, will use automatically
|
||||
the :program:`platex/dvipdfmx` latex to PDF pipeline.
|
||||
|
||||
**info**
|
||||
Build Texinfo files and run them through :program:`makeinfo`.
|
||||
|
||||
.. important::
|
||||
Sphinx only recognizes the ``-M`` option if it is placed first.
|
||||
|
||||
.. versionadded:: 1.2.1
|
||||
|
||||
.. option:: -a
|
||||
|
||||
If given, always write all output files. The default is to only write output
|
||||
files for new and changed source files. (This may not apply to all
|
||||
builders.)
|
||||
|
||||
.. option:: -E
|
||||
|
||||
Don't use a saved :term:`environment` (the structure caching all
|
||||
cross-references), but rebuild it completely. The default is to only read
|
||||
and parse source files that are new or have changed since the last run.
|
||||
|
||||
.. option:: -t tag
|
||||
|
||||
Define the tag *tag*. This is relevant for :rst:dir:`only` directives that
|
||||
only include their content if this tag is set.
|
||||
|
||||
.. versionadded:: 0.6
|
||||
|
||||
.. option:: -d path
|
||||
|
||||
Since Sphinx has to read and parse all source files before it can write an
|
||||
output file, the parsed source files are cached as "doctree pickles".
|
||||
Normally, these files are put in a directory called :file:`.doctrees` under
|
||||
the build directory; with this option you can select a different cache
|
||||
directory (the doctrees can be shared between all builders).
|
||||
|
||||
.. option:: -j N
|
||||
|
||||
Distribute the build over *N* processes in parallel, to make building on
|
||||
multiprocessor machines more effective. Note that not all parts and not all
|
||||
builders of Sphinx can be parallelized. If ``auto`` argument is given,
|
||||
Sphinx uses the number of CPUs as *N*.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
This option should be considered *experimental*.
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
Support ``auto`` argument.
|
||||
|
||||
.. option:: -c path
|
||||
|
||||
Don't look for the :file:`conf.py` in the source directory, but use the given
|
||||
configuration directory instead. Note that various other files and paths
|
||||
given by configuration values are expected to be relative to the
|
||||
configuration directory, so they will have to be present at this location
|
||||
too.
|
||||
|
||||
.. versionadded:: 0.3
|
||||
|
||||
.. option:: -C
|
||||
|
||||
Don't look for a configuration file; only take options via the ``-D`` option.
|
||||
|
||||
.. versionadded:: 0.5
|
||||
|
||||
.. option:: -D setting=value
|
||||
|
||||
Override a configuration value set in the :file:`conf.py` file. The value
|
||||
must be a number, string, list or dictionary value.
|
||||
|
||||
For lists, you can separate elements with a comma like this: ``-D
|
||||
html_theme_path=path1,path2``.
|
||||
|
||||
For dictionary values, supply the setting name and key like this:
|
||||
``-D latex_elements.docclass=scrartcl``.
|
||||
|
||||
For boolean values, use ``0`` or ``1`` as the value.
|
||||
|
||||
.. versionchanged:: 0.6
|
||||
The value can now be a dictionary value.
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
The value can now also be a list value.
|
||||
|
||||
.. option:: -A name=value
|
||||
|
||||
Make the *name* assigned to *value* in the HTML templates.
|
||||
|
||||
.. versionadded:: 0.5
|
||||
|
||||
.. option:: -n
|
||||
|
||||
Run in nit-picky mode. Currently, this generates warnings for all missing
|
||||
references. See the config value :confval:`nitpick_ignore` for a way to
|
||||
exclude some references as "known missing".
|
||||
|
||||
.. option:: -N
|
||||
|
||||
Do not emit colored output.
|
||||
|
||||
.. option:: -v
|
||||
|
||||
Increase verbosity (loglevel). This option can be given up to three times
|
||||
to get more debug logging output. It implies :option:`-T`.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
.. option:: -q
|
||||
|
||||
Do not output anything on standard output, only write warnings and errors to
|
||||
standard error.
|
||||
|
||||
.. option:: -Q
|
||||
|
||||
Do not output anything on standard output, also suppress warnings. Only
|
||||
errors are written to standard error.
|
||||
|
||||
.. option:: -w file
|
||||
|
||||
Write warnings (and errors) to the given file, in addition to standard error.
|
||||
|
||||
.. option:: -W
|
||||
|
||||
Turn warnings into errors. This means that the build stops at the first
|
||||
warning and ``sphinx-build`` exits with exit status 1.
|
||||
|
||||
.. option:: --keep-going
|
||||
|
||||
With -W option, keep going processing when getting warnings to the end
|
||||
of build, and ``sphinx-build`` exits with exit status 1.
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
.. option:: -T
|
||||
|
||||
Display the full traceback when an unhandled exception occurs. Otherwise,
|
||||
only a summary is displayed and the traceback information is saved to a file
|
||||
for further analysis.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
.. option:: -P
|
||||
|
||||
(Useful for debugging only.) Run the Python debugger, :mod:`pdb`, if an
|
||||
unhandled exception occurs while building.
|
||||
|
||||
.. option:: -h, --help, --version
|
||||
|
||||
Display usage summary or Sphinx version.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
You can also give one or more filenames on the command line after the source
|
||||
and build directories. Sphinx will then try to build only these output files
|
||||
(and their dependencies).
|
||||
|
||||
Environment Variables
|
||||
---------------------
|
||||
|
||||
The :program:`sphinx-build` refers following environment variables:
|
||||
|
||||
.. describe:: MAKE
|
||||
|
||||
A path to make command. A command name is also allowed.
|
||||
:program:`sphinx-build` uses it to invoke sub-build process on make-mode.
|
||||
|
||||
.. _makefile_options:
|
||||
|
||||
.. rubric:: Makefile Options
|
||||
|
||||
The :file:`Makefile` and :file:`make.bat` files created by
|
||||
:program:`sphinx-quickstart` usually run :program:`sphinx-build` only with the
|
||||
:option:`-b` and :option:`-d` options. However, they support the following
|
||||
variables to customize behavior:
|
||||
|
||||
.. describe:: PAPER
|
||||
|
||||
This sets the ``'papersize'`` key of :confval:`latex_elements`:
|
||||
i.e. ``PAPER=a4`` sets it to ``'a4paper'`` and ``PAPER=letter`` to
|
||||
``'letterpaper'``.
|
||||
|
||||
.. note::
|
||||
|
||||
Usage of this environment variable got broken at Sphinx 1.5 as
|
||||
``a4`` or ``letter`` ended up as option to LaTeX document in
|
||||
place of the needed ``a4paper``, resp. ``letterpaper``. Fixed at
|
||||
1.7.7.
|
||||
|
||||
.. describe:: SPHINXBUILD
|
||||
|
||||
The command to use instead of ``sphinx-build``.
|
||||
|
||||
.. describe:: BUILDDIR
|
||||
|
||||
The build directory to use instead of the one chosen in
|
||||
:program:`sphinx-quickstart`.
|
||||
|
||||
.. describe:: SPHINXOPTS
|
||||
|
||||
Additional options for :program:`sphinx-build`.
|
||||
|
||||
.. _when-deprecation-warnings-are-displayed:
|
||||
|
||||
Deprecation Warnings
|
||||
--------------------
|
||||
|
||||
If any deprecation warning like ``RemovedInSphinxXXXWarning`` are displayed
|
||||
when building a user's document, some Sphinx extension is using deprecated
|
||||
features. In that case, please report it to author of the extension.
|
||||
|
||||
To disable the deprecation warnings, please set ``PYTHONWARNINGS=`` environment
|
||||
variable to your environment. For example:
|
||||
|
||||
* ``PYTHONWARNINGS= make html`` (Linux/Mac)
|
||||
* ``export PYTHONWARNINGS=`` and do ``make html`` (Linux/Mac)
|
||||
* ``set PYTHONWARNINGS=`` and do ``make html`` (Windows)
|
||||
* modify your Makefile/make.bat and set the environment variable
|
||||
|
||||
See also
|
||||
--------
|
||||
|
||||
:manpage:`sphinx-quickstart(1)`
|
||||
|
||||
Author
|
||||
------
|
||||
|
||||
Georg Brandl <georg@python.org>, Armin Ronacher <armin.ronacher@active-4.com> et
|
||||
al.
|
||||
|
||||
This manual page was initially written by Mikhail Gusarov
|
||||
<dottedmag@dottedmag.net>, for the Debian project.
|
||||
+151
-15
@@ -1,14 +1,11 @@
|
||||
:orphan:
|
||||
|
||||
sphinx-quickstart manual page
|
||||
=============================
|
||||
sphinx-quickstart
|
||||
=================
|
||||
|
||||
Synopsis
|
||||
--------
|
||||
|
||||
**sphinx-quickstart**
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
@@ -16,18 +13,157 @@ Description
|
||||
about your project and then generates a complete documentation directory and
|
||||
sample Makefile to be used with :manpage:`sphinx-build(1)`.
|
||||
|
||||
Options
|
||||
-------
|
||||
|
||||
.. program:: sphinx-quickstart
|
||||
|
||||
.. option:: -q, --quiet
|
||||
|
||||
Quiet mode that will skip interactive wizard to specify options.
|
||||
This option requires `-p`, `-a` and `-v` options.
|
||||
|
||||
.. option:: -h, --help, --version
|
||||
|
||||
Display usage summary or Sphinx version.
|
||||
|
||||
.. rubric:: Structure Options
|
||||
|
||||
.. option:: --sep
|
||||
|
||||
If specified, separate source and build directories.
|
||||
|
||||
.. option:: --dot=DOT
|
||||
|
||||
Inside the root directory, two more directories will be created;
|
||||
"_templates" for custom HTML templates and "_static" for custom stylesheets
|
||||
and other static files. You can enter another prefix (such as ".") to
|
||||
replace the underscore.
|
||||
|
||||
.. rubric:: Project Basic Options
|
||||
|
||||
.. option:: -p PROJECT, --project=PROJECT
|
||||
|
||||
Project name will be set. (see :confval:`project`).
|
||||
|
||||
.. option:: -a AUTHOR, --author=AUTHOR
|
||||
|
||||
Author names. (see :confval:`copyright`).
|
||||
|
||||
.. option:: -v VERSION
|
||||
|
||||
Version of project. (see :confval:`version`).
|
||||
|
||||
.. option:: -r RELEASE, --release=RELEASE
|
||||
|
||||
Release of project. (see :confval:`release`).
|
||||
|
||||
.. option:: -l LANGUAGE, --language=LANGUAGE
|
||||
|
||||
Document language. (see :confval:`language`).
|
||||
|
||||
.. option:: --suffix=SUFFIX
|
||||
|
||||
Source file suffix. (see :confval:`source_suffix`).
|
||||
|
||||
.. option:: --master=MASTER
|
||||
|
||||
Master document name. (see :confval:`master_doc`).
|
||||
|
||||
.. option:: --epub
|
||||
|
||||
Use epub.
|
||||
|
||||
.. rubric:: Extension Options
|
||||
|
||||
.. option:: --ext-autodoc
|
||||
|
||||
Enable `sphinx.ext.autodoc` extension.
|
||||
|
||||
.. option:: --ext-doctest
|
||||
|
||||
Enable `sphinx.ext.doctest` extension.
|
||||
|
||||
.. option:: --ext-intersphinx
|
||||
|
||||
Enable `sphinx.ext.intersphinx` extension.
|
||||
|
||||
.. option:: --ext-todo
|
||||
|
||||
Enable `sphinx.ext.todo` extension.
|
||||
|
||||
.. option:: --ext-coverage
|
||||
|
||||
Enable `sphinx.ext.coverage` extension.
|
||||
|
||||
.. option:: --ext-imgmath
|
||||
|
||||
Enable `sphinx.ext.imgmath` extension.
|
||||
|
||||
.. option:: --ext-mathjax
|
||||
|
||||
Enable `sphinx.ext.mathjax` extension.
|
||||
|
||||
.. option:: --ext-ifconfig
|
||||
|
||||
Enable `sphinx.ext.ifconfig` extension.
|
||||
|
||||
.. option:: --ext-viewcode
|
||||
|
||||
Enable `sphinx.ext.viewcode` extension.
|
||||
|
||||
.. option:: --ext-githubpages
|
||||
|
||||
Enable `sphinx.ext.githubpages` extension.
|
||||
|
||||
.. option:: --extensions=EXTENSIONS
|
||||
|
||||
Enable arbitrary extensions.
|
||||
|
||||
.. rubric:: Makefile and Batchfile Creation Options
|
||||
|
||||
.. option:: --use-make-mode (-m), --no-use-make-mode (-M)
|
||||
|
||||
:file:`Makefile/make.bat` uses (or doesn't use) :ref:`make-mode <make_mode>`.
|
||||
Default is ``use``, which generates a more concise :file:`Makefile/make.bat`.
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
make-mode is default.
|
||||
|
||||
.. option:: --makefile, --no-makefile
|
||||
|
||||
Create (or not create) makefile.
|
||||
|
||||
.. option:: --batchfile, --no-batchfile
|
||||
|
||||
Create (or not create) batchfile
|
||||
|
||||
.. rubric:: Project templating
|
||||
|
||||
.. versionadded:: 1.5
|
||||
Project templating options for sphinx-quickstart
|
||||
|
||||
.. option:: -t, --templatedir=TEMPLATEDIR
|
||||
|
||||
Template directory for template files. You can modify the templates of
|
||||
sphinx project files generated by quickstart. Following Jinja2 template
|
||||
files are allowed:
|
||||
|
||||
* ``master_doc.rst_t``
|
||||
* ``conf.py_t``
|
||||
* ``Makefile_t``
|
||||
* ``Makefile.new_t``
|
||||
* ``make.bat_t``
|
||||
* ``make.bat.new_t``
|
||||
|
||||
In detail, please refer the system template files Sphinx provides.
|
||||
(``sphinx/templates/quickstart``)
|
||||
|
||||
.. option:: -d NAME=VALUE
|
||||
|
||||
Define a template variable
|
||||
|
||||
See also
|
||||
--------
|
||||
|
||||
:manpage:`sphinx-build(1)`
|
||||
|
||||
|
||||
Author
|
||||
------
|
||||
|
||||
Georg Brandl <georg@python.org>, Armin Ronacher <armin.ronacher@active-4.com> et
|
||||
al.
|
||||
|
||||
This manual page was initially written by Mikhail Gusarov
|
||||
<dottedmag@dottedmag.net>, for the Debian project.
|
||||
@@ -1,45 +0,0 @@
|
||||
.. highlightlang:: python
|
||||
|
||||
.. _markdown:
|
||||
|
||||
Markdown support
|
||||
================
|
||||
|
||||
`Markdown <https://daringfireball.net/projects/markdown/>`__ is a lightweight markup language with a simplistic plain
|
||||
text formatting syntax.
|
||||
It exists in many syntactically different *flavors*.
|
||||
To support Markdown-based documentation, Sphinx can use
|
||||
`recommonmark <http://recommonmark.readthedocs.io/en/latest/index.html>`__.
|
||||
recommonmark is a Docutils bridge to `CommonMark-py <https://github.com/rtfd/CommonMark-py>`__, a
|
||||
Python package for parsing the `CommonMark <http://commonmark.org/>`__ Markdown flavor.
|
||||
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
To configure your Sphinx project for Markdown support, proceed as follows:
|
||||
|
||||
#. Install recommonmark:
|
||||
|
||||
::
|
||||
|
||||
pip install recommonmark
|
||||
|
||||
#. Add the Markdown parser to the ``source_parsers`` configuration variable in your Sphinx configuration file:
|
||||
|
||||
::
|
||||
|
||||
source_parsers = {
|
||||
'.md': 'recommonmark.parser.CommonMarkParser',
|
||||
}
|
||||
|
||||
You can replace `.md` with a filename extension of your choice.
|
||||
|
||||
#. Add the Markdown filename extension to the ``source_suffix`` configuration variable:
|
||||
|
||||
::
|
||||
|
||||
source_suffix = ['.rst', '.md']
|
||||
|
||||
#. You can further configure recommonmark to allow custom syntax that standard CommonMark doesn't support. Read more in
|
||||
the `recommonmark documentation <http://recommonmark.readthedocs.io/en/latest/auto_structify.html>`__.
|
||||
@@ -1,268 +0,0 @@
|
||||
.. highlight:: rest
|
||||
|
||||
.. _code-examples:
|
||||
|
||||
Showing code examples
|
||||
---------------------
|
||||
|
||||
.. index:: pair: code; examples
|
||||
single: sourcecode
|
||||
|
||||
Examples of Python source code or interactive sessions are represented using
|
||||
standard reST literal blocks. They are started by a ``::`` at the end of the
|
||||
preceding paragraph and delimited by indentation.
|
||||
|
||||
Representing an interactive session requires including the prompts and output
|
||||
along with the Python code. No special markup is required for interactive
|
||||
sessions. After the last line of input or output presented, there should not be
|
||||
an "unused" primary prompt; this is an example of what *not* to do::
|
||||
|
||||
>>> 1 + 1
|
||||
2
|
||||
>>>
|
||||
|
||||
Syntax highlighting is done with `Pygments <http://pygments.org>`_ and handled
|
||||
in a smart way:
|
||||
|
||||
* There is a "highlighting language" for each source file. Per default, this is
|
||||
``'python'`` as the majority of files will have to highlight Python snippets,
|
||||
but the doc-wide default can be set with the :confval:`highlight_language`
|
||||
config value.
|
||||
|
||||
* Within Python highlighting mode, interactive sessions are recognized
|
||||
automatically and highlighted appropriately. Normal Python code is only
|
||||
highlighted if it is parseable (so you can use Python as the default, but
|
||||
interspersed snippets of shell commands or other code blocks will not be
|
||||
highlighted as Python).
|
||||
|
||||
* The highlighting language can be changed using the ``highlight`` directive,
|
||||
used as follows:
|
||||
|
||||
.. rst:directive:: .. highlight:: language
|
||||
|
||||
Example::
|
||||
|
||||
.. highlight:: c
|
||||
|
||||
This language is used until the next ``highlight`` directive is encountered.
|
||||
|
||||
* For documents that have to show snippets in different languages, there's also
|
||||
a :rst:dir:`code-block` directive that is given the highlighting language
|
||||
directly:
|
||||
|
||||
.. rst:directive:: .. code-block:: language
|
||||
|
||||
Use it like this::
|
||||
|
||||
.. code-block:: ruby
|
||||
|
||||
Some Ruby code.
|
||||
|
||||
The directive's alias name :rst:dir:`sourcecode` works as well.
|
||||
|
||||
* The valid values for the highlighting language are:
|
||||
|
||||
* ``none`` (no highlighting)
|
||||
* ``python`` (the default when :confval:`highlight_language` isn't set)
|
||||
* ``guess`` (let Pygments guess the lexer based on contents, only works with
|
||||
certain well-recognizable languages)
|
||||
* ``rest``
|
||||
* ``c``
|
||||
* ... and any other `lexer alias that Pygments supports
|
||||
<http://pygments.org/docs/lexers/>`_.
|
||||
|
||||
* If highlighting with the selected language fails (i.e. Pygments emits an
|
||||
"Error" token), the block is not highlighted in any way.
|
||||
|
||||
Line numbers
|
||||
^^^^^^^^^^^^
|
||||
|
||||
Pygments can generate line numbers for code blocks. For
|
||||
automatically-highlighted blocks (those started by ``::``), line numbers must be
|
||||
switched on in a :rst:dir:`highlight` directive, with the ``linenothreshold``
|
||||
option::
|
||||
|
||||
.. highlight:: python
|
||||
:linenothreshold: 5
|
||||
|
||||
This will produce line numbers for all code blocks longer than five lines.
|
||||
|
||||
For :rst:dir:`code-block` blocks, a ``linenos`` flag option can be given to
|
||||
switch on line numbers for the individual block::
|
||||
|
||||
.. code-block:: ruby
|
||||
:linenos:
|
||||
|
||||
Some more Ruby code.
|
||||
|
||||
The first line number can be selected with the ``lineno-start`` option. If
|
||||
present, ``linenos`` is automatically activated as well::
|
||||
|
||||
.. code-block:: ruby
|
||||
:lineno-start: 10
|
||||
|
||||
Some more Ruby code, with line numbering starting at 10.
|
||||
|
||||
Additionally, an ``emphasize-lines`` option can be given to have Pygments
|
||||
emphasize particular lines::
|
||||
|
||||
.. code-block:: python
|
||||
:emphasize-lines: 3,5
|
||||
|
||||
def some_function():
|
||||
interesting = False
|
||||
print 'This line is highlighted.'
|
||||
print 'This one is not...'
|
||||
print '...but this one is.'
|
||||
|
||||
.. versionchanged:: 1.1
|
||||
``emphasize-lines`` has been added.
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
``lineno-start`` has been added.
|
||||
|
||||
|
||||
Includes
|
||||
^^^^^^^^
|
||||
|
||||
.. rst:directive:: .. literalinclude:: filename
|
||||
|
||||
Longer displays of verbatim text may be included by storing the example text
|
||||
in an external file containing only plain text. The file may be included
|
||||
using the ``literalinclude`` directive. [1]_ For example, to include the
|
||||
Python source file :file:`example.py`, use::
|
||||
|
||||
.. literalinclude:: example.py
|
||||
|
||||
The file name is usually relative to the current file's path. However, if it
|
||||
is absolute (starting with ``/``), it is relative to the top source
|
||||
directory.
|
||||
|
||||
Tabs in the input are expanded if you give a ``tab-width`` option with the
|
||||
desired tab width.
|
||||
|
||||
Like :rst:dir:`code-block`, the directive supports the ``linenos`` flag
|
||||
option to switch on line numbers, the ``lineno-start`` option to select the
|
||||
first line number, the ``emphasize-lines`` option to emphasize particular
|
||||
lines, and a ``language`` option to select a language different from the
|
||||
current file's standard language. Example with options::
|
||||
|
||||
.. literalinclude:: example.rb
|
||||
:language: ruby
|
||||
:emphasize-lines: 12,15-18
|
||||
:linenos:
|
||||
|
||||
Include files are assumed to be encoded in the :confval:`source_encoding`.
|
||||
If the file has a different encoding, you can specify it with the
|
||||
``encoding`` option::
|
||||
|
||||
.. literalinclude:: example.py
|
||||
:encoding: latin-1
|
||||
|
||||
The directive also supports including only parts of the file. If it is a
|
||||
Python module, you can select a class, function or method to include using
|
||||
the ``pyobject`` option::
|
||||
|
||||
.. literalinclude:: example.py
|
||||
:pyobject: Timer.start
|
||||
|
||||
This would only include the code lines belonging to the ``start()`` method in
|
||||
the ``Timer`` class within the file.
|
||||
|
||||
Alternately, you can specify exactly which lines to include by giving a
|
||||
``lines`` option::
|
||||
|
||||
.. literalinclude:: example.py
|
||||
:lines: 1,3,5-10,20-
|
||||
|
||||
This includes the lines 1, 3, 5 to 10 and lines 20 to the last line.
|
||||
|
||||
Another way to control which part of the file is included is to use the
|
||||
``start-after`` and ``end-before`` options (or only one of them). If
|
||||
``start-after`` is given as a string option, only lines that follow the first
|
||||
line containing that string are included. If ``end-before`` is given as a
|
||||
string option, only lines that precede the first lines containing that string
|
||||
are included.
|
||||
|
||||
With lines selected using ``start-after`` it is still possible to use
|
||||
``lines``, the first allowed line having by convention the line number ``1``.
|
||||
|
||||
When lines have been selected in any of the ways described above, the
|
||||
line numbers in ``emphasize-lines`` also refer to the selection, with the
|
||||
first selected line having number ``1``.
|
||||
|
||||
When specifying particular parts of a file to display, it can be useful to
|
||||
display the original line numbers. This can be done using the
|
||||
``lineno-match`` option, which is however allowed only when the selection
|
||||
consists of contiguous lines.
|
||||
|
||||
You can prepend and/or append a line to the included code, using the
|
||||
``prepend`` and ``append`` option, respectively. This is useful e.g. for
|
||||
highlighting PHP code that doesn't include the ``<?php``/``?>`` markers.
|
||||
|
||||
|
||||
If you want to show the diff of the code, you can specify the old
|
||||
file by giving a ``diff`` option::
|
||||
|
||||
.. literalinclude:: example.py
|
||||
:diff: example.py.orig
|
||||
|
||||
This shows the diff between example.py and example.py.orig with unified diff
|
||||
format.
|
||||
|
||||
.. versionadded:: 0.4.3
|
||||
The ``encoding`` option.
|
||||
.. versionadded:: 0.6
|
||||
The ``pyobject``, ``lines``, ``start-after`` and ``end-before`` options,
|
||||
as well as support for absolute filenames.
|
||||
.. versionadded:: 1.0
|
||||
The ``prepend`` and ``append`` options, as well as ``tab-width``.
|
||||
.. versionadded:: 1.3
|
||||
The ``diff`` option.
|
||||
The ``lineno-match`` option.
|
||||
.. versionchanged:: 1.6
|
||||
With both ``start-after`` and ``lines`` in use, the first line as per
|
||||
``start-after`` is considered to be with line number ``1`` for ``lines``.
|
||||
|
||||
Caption and name
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
A ``caption`` option can be given to show that name before the code block.
|
||||
A ``name`` option can be provided implicit target name that can be referenced
|
||||
by using :rst:role:`ref`.
|
||||
For example::
|
||||
|
||||
.. code-block:: python
|
||||
:caption: this.py
|
||||
:name: this-py
|
||||
|
||||
print 'Explicit is better than implicit.'
|
||||
|
||||
|
||||
:rst:dir:`literalinclude` also supports the ``caption`` and ``name`` option.
|
||||
``caption`` has an additional feature that if you leave the value empty, the shown
|
||||
filename will be exactly the one given as an argument.
|
||||
|
||||
|
||||
Dedent
|
||||
^^^^^^
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
A ``dedent`` option can be given to strip indentation characters from the code
|
||||
block. For example::
|
||||
|
||||
.. literalinclude:: example.rb
|
||||
:language: ruby
|
||||
:dedent: 4
|
||||
:lines: 10-15
|
||||
|
||||
:rst:dir:`code-block` also supports the ``dedent`` option.
|
||||
|
||||
|
||||
.. rubric:: Footnotes
|
||||
|
||||
.. [1] There is a standard ``.. include`` directive, but it raises errors if the
|
||||
file is not found. This one only emits a warning.
|
||||
@@ -1,19 +0,0 @@
|
||||
.. _sphinxmarkup:
|
||||
|
||||
Sphinx Markup Constructs
|
||||
========================
|
||||
|
||||
Sphinx adds a lot of new directives and interpreted text roles to `standard reST
|
||||
markup`_. This section contains the reference material for these facilities.
|
||||
|
||||
.. toctree::
|
||||
|
||||
toctree
|
||||
para
|
||||
code
|
||||
inline
|
||||
misc
|
||||
|
||||
More markup is added by :ref:`domains`.
|
||||
|
||||
.. _standard reST markup: http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html
|
||||
@@ -1,339 +0,0 @@
|
||||
.. highlight:: rest
|
||||
|
||||
Miscellaneous markup
|
||||
====================
|
||||
|
||||
.. _metadata:
|
||||
|
||||
File-wide metadata
|
||||
------------------
|
||||
|
||||
reST has the concept of "field lists"; these are a sequence of fields marked up
|
||||
like this::
|
||||
|
||||
:fieldname: Field content
|
||||
|
||||
A field list near the top of a file is parsed by docutils as the "docinfo"
|
||||
which is normally used to record the author, date of publication and other
|
||||
metadata. *In Sphinx*, a field list preceding any other markup is moved from
|
||||
the docinfo to the Sphinx environment as document metadata and is not displayed
|
||||
in the output; a field list appearing after the document title will be part of
|
||||
the docinfo as normal and will be displayed in the output.
|
||||
|
||||
At the moment, these metadata fields are recognized:
|
||||
|
||||
``tocdepth``
|
||||
The maximum depth for a table of contents of this file.
|
||||
|
||||
.. versionadded:: 0.4
|
||||
|
||||
``nocomments``
|
||||
If set, the web application won't display a comment form for a page generated
|
||||
from this source file.
|
||||
|
||||
``orphan``
|
||||
If set, warnings about this file not being included in any toctree will be
|
||||
suppressed.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
|
||||
Meta-information markup
|
||||
-----------------------
|
||||
|
||||
.. rst:directive:: .. sectionauthor:: name <email>
|
||||
|
||||
Identifies the author of the current section. The argument should include
|
||||
the author's name such that it can be used for presentation and email
|
||||
address. The domain name portion of the address should be lower case.
|
||||
Example::
|
||||
|
||||
.. sectionauthor:: Guido van Rossum <guido@python.org>
|
||||
|
||||
By default, this markup isn't reflected in the output in any way (it helps
|
||||
keep track of contributions), but you can set the configuration value
|
||||
:confval:`show_authors` to ``True`` to make them produce a paragraph in the
|
||||
output.
|
||||
|
||||
|
||||
.. rst:directive:: .. codeauthor:: name <email>
|
||||
|
||||
The :rst:dir:`codeauthor` directive, which can appear multiple times, names
|
||||
the authors of the described code, just like :rst:dir:`sectionauthor` names
|
||||
the author(s) of a piece of documentation. It too only produces output if
|
||||
the :confval:`show_authors` configuration value is ``True``.
|
||||
|
||||
|
||||
Index-generating markup
|
||||
-----------------------
|
||||
|
||||
Sphinx automatically creates index entries from all object descriptions (like
|
||||
functions, classes or attributes) like discussed in :ref:`domains`.
|
||||
|
||||
However, there is also explicit markup available, to make the index more
|
||||
comprehensive and enable index entries in documents where information is not
|
||||
mainly contained in information units, such as the language reference.
|
||||
|
||||
.. rst:directive:: .. index:: <entries>
|
||||
|
||||
This directive contains one or more index entries. Each entry consists of a
|
||||
type and a value, separated by a colon.
|
||||
|
||||
For example::
|
||||
|
||||
.. index::
|
||||
single: execution; context
|
||||
module: __main__
|
||||
module: sys
|
||||
triple: module; search; path
|
||||
|
||||
The execution context
|
||||
---------------------
|
||||
|
||||
...
|
||||
|
||||
This directive contains five entries, which will be converted to entries in
|
||||
the generated index which link to the exact location of the index statement
|
||||
(or, in case of offline media, the corresponding page number).
|
||||
|
||||
Since index directives generate cross-reference targets at their location in
|
||||
the source, it makes sense to put them *before* the thing they refer to --
|
||||
e.g. a heading, as in the example above.
|
||||
|
||||
The possible entry types are:
|
||||
|
||||
single
|
||||
Creates a single index entry. Can be made a subentry by separating the
|
||||
subentry text with a semicolon (this notation is also used below to
|
||||
describe what entries are created).
|
||||
pair
|
||||
``pair: loop; statement`` is a shortcut that creates two index entries,
|
||||
namely ``loop; statement`` and ``statement; loop``.
|
||||
triple
|
||||
Likewise, ``triple: module; search; path`` is a shortcut that creates
|
||||
three index entries, which are ``module; search path``, ``search; path,
|
||||
module`` and ``path; module search``.
|
||||
see
|
||||
``see: entry; other`` creates an index entry that refers from ``entry`` to
|
||||
``other``.
|
||||
seealso
|
||||
Like ``see``, but inserts "see also" instead of "see".
|
||||
module, keyword, operator, object, exception, statement, builtin
|
||||
These all create two index entries. For example, ``module: hashlib``
|
||||
creates the entries ``module; hashlib`` and ``hashlib; module``. (These
|
||||
are Python-specific and therefore deprecated.)
|
||||
|
||||
You can mark up "main" index entries by prefixing them with an exclamation
|
||||
mark. The references to "main" entries are emphasized in the generated
|
||||
index. For example, if two pages contain ::
|
||||
|
||||
.. index:: Python
|
||||
|
||||
and one page contains ::
|
||||
|
||||
.. index:: ! Python
|
||||
|
||||
then the backlink to the latter page is emphasized among the three backlinks.
|
||||
|
||||
For index directives containing only "single" entries, there is a shorthand
|
||||
notation::
|
||||
|
||||
.. index:: BNF, grammar, syntax, notation
|
||||
|
||||
This creates four index entries.
|
||||
|
||||
.. versionchanged:: 1.1
|
||||
Added ``see`` and ``seealso`` types, as well as marking main entries.
|
||||
|
||||
.. rst:role:: index
|
||||
|
||||
While the :rst:dir:`index` directive is a block-level markup and links to the
|
||||
beginning of the next paragraph, there is also a corresponding role that sets
|
||||
the link target directly where it is used.
|
||||
|
||||
The content of the role can be a simple phrase, which is then kept in the
|
||||
text and used as an index entry. It can also be a combination of text and
|
||||
index entry, styled like with explicit targets of cross-references. In that
|
||||
case, the "target" part can be a full entry as described for the directive
|
||||
above. For example::
|
||||
|
||||
This is a normal reST :index:`paragraph` that contains several
|
||||
:index:`index entries <pair: index; entry>`.
|
||||
|
||||
.. versionadded:: 1.1
|
||||
|
||||
|
||||
.. _tags:
|
||||
|
||||
Including content based on tags
|
||||
-------------------------------
|
||||
|
||||
.. rst:directive:: .. only:: <expression>
|
||||
|
||||
Include the content of the directive only if the *expression* is true. The
|
||||
expression should consist of tags, like this::
|
||||
|
||||
.. only:: html and draft
|
||||
|
||||
Undefined tags are false, defined tags (via the ``-t`` command-line option or
|
||||
within :file:`conf.py`, see :ref:`here <conf-tags>`) are true. Boolean
|
||||
expressions, also using parentheses (like ``html and (latex or draft)``) are
|
||||
supported.
|
||||
|
||||
The *format* and the *name* of the current builder (``html``, ``latex`` or
|
||||
``text``) are always set as a tag [#]_. To make the distinction between
|
||||
format and name explicit, they are also added with the prefix ``format_`` and
|
||||
``builder_``, e.g. the epub builder defines the tags ``html``, ``epub``,
|
||||
``format_html`` and ``builder_epub``.
|
||||
|
||||
These standard tags are set *after* the configuration file is read, so they
|
||||
are not available there.
|
||||
|
||||
All tags must follow the standard Python identifier syntax as set out in
|
||||
the `Identifiers and keywords
|
||||
<https://docs.python.org/2/reference/lexical_analysis.html#identifiers>`_
|
||||
documentation. That is, a tag expression may only consist of tags that
|
||||
conform to the syntax of Python variables. In ASCII, this consists of the
|
||||
uppercase and lowercase letters ``A`` through ``Z``, the underscore ``_``
|
||||
and, except for the first character, the digits ``0`` through ``9``.
|
||||
|
||||
.. versionadded:: 0.6
|
||||
.. versionchanged:: 1.2
|
||||
Added the name of the builder and the prefixes.
|
||||
|
||||
.. warning::
|
||||
|
||||
This directive is designed to control only content of document. It could
|
||||
not control sections, labels and so on.
|
||||
|
||||
|
||||
Tables
|
||||
------
|
||||
|
||||
Use :ref:`reStructuredText tables <rst-tables>`, i.e. either
|
||||
|
||||
- grid table syntax (:duref:`ref <grid-tables>`),
|
||||
- simple table syntax (:duref:`ref <simple-tables>`),
|
||||
- :dudir:`csv-table` syntax,
|
||||
- or :dudir:`list-table` syntax.
|
||||
|
||||
The :dudir:`table` directive serves as optional wrapper of the *grid* and
|
||||
*simple* syntaxes.
|
||||
|
||||
They work fine in
|
||||
HTML output, however there are some gotchas when using tables in LaTeX: the
|
||||
column width is hard to determine correctly automatically. For this reason, the
|
||||
following directive exists:
|
||||
|
||||
.. rst:directive:: .. tabularcolumns:: column spec
|
||||
|
||||
This directive gives a "column spec" for the next table occurring in the
|
||||
source file. The spec is the second argument to the LaTeX ``tabulary``
|
||||
package's environment (which Sphinx uses to translate tables). It can have
|
||||
values like ::
|
||||
|
||||
|l|l|l|
|
||||
|
||||
which means three left-adjusted, nonbreaking columns. For columns with
|
||||
longer text that should automatically be broken, use either the standard
|
||||
``p{width}`` construct, or tabulary's automatic specifiers:
|
||||
|
||||
+-----+------------------------------------------+
|
||||
|``L``| flush left column with automatic width |
|
||||
+-----+------------------------------------------+
|
||||
|``R``| flush right column with automatic width |
|
||||
+-----+------------------------------------------+
|
||||
|``C``| centered column with automatic width |
|
||||
+-----+------------------------------------------+
|
||||
|``J``| justified column with automatic width |
|
||||
+-----+------------------------------------------+
|
||||
|
||||
The automatic widths of the ``LRCJ`` columns are attributed by ``tabulary``
|
||||
in proportion to the observed shares in a first pass where the table cells
|
||||
are rendered at their natural "horizontal" widths.
|
||||
|
||||
By default, Sphinx uses a table layout with ``J`` for every column.
|
||||
|
||||
.. versionadded:: 0.3
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
Merged cells may now contain multiple paragraphs and are much better
|
||||
handled, thanks to custom Sphinx LaTeX macros. This novel situation
|
||||
motivated the switch to ``J`` specifier and not ``L`` by default.
|
||||
|
||||
.. hint::
|
||||
|
||||
Sphinx actually uses ``T`` specifier having done ``\newcolumntype{T}{J}``.
|
||||
To revert to previous default, insert ``\newcolumntype{T}{L}`` in the
|
||||
LaTeX preamble (see :confval:`latex_elements`).
|
||||
|
||||
A frequent issue with tabulary is that columns with little contents are
|
||||
"squeezed". The minimal column width is a tabulary parameter called
|
||||
``\tymin``. You may set it globally in the LaTeX preamble via
|
||||
``\setlength{\tymin}{40pt}`` for example.
|
||||
|
||||
Else, use the :rst:dir:`tabularcolumns` directive with an explicit
|
||||
``p{40pt}`` (for example) for that column. You may use also ``l``
|
||||
specifier but this makes the task of setting column widths more difficult
|
||||
if some merged cell intersects that column.
|
||||
|
||||
.. warning::
|
||||
|
||||
Tables with more than 30 rows are rendered using ``longtable``, not
|
||||
``tabulary``, in order to allow pagebreaks. The ``L``, ``R``, ... specifiers
|
||||
do not work for these tables.
|
||||
|
||||
Tables that contain list-like elements such as object descriptions,
|
||||
blockquotes or any kind of lists cannot be set out of the box with
|
||||
``tabulary``. They are therefore set with the standard LaTeX ``tabular`` (or
|
||||
``longtable``) environment if you don't give a ``tabularcolumns`` directive.
|
||||
If you do, the table will be set with ``tabulary`` but you must use the
|
||||
``p{width}`` construct (or Sphinx's ``\X`` and ``\Y`` specifiers described
|
||||
below) for the columns containing these elements.
|
||||
|
||||
Literal blocks do not work with ``tabulary`` at all, so tables containing
|
||||
a literal block are always set with ``tabular``. The verbatim environment
|
||||
used for literal blocks only works in ``p{width}`` (and ``\X`` or ``\Y``)
|
||||
columns, hence Sphinx generates such column specs for tables containing
|
||||
literal blocks.
|
||||
|
||||
Since Sphinx 1.5, the ``\X{a}{b}`` specifier is used (there *is* a backslash
|
||||
in the specifier letter). It is like ``p{width}`` with the width set to a
|
||||
fraction ``a/b`` of the current line width. You can use it in the
|
||||
:rst:dir:`tabularcolumns` (it is not a problem if some LaTeX macro is also
|
||||
called ``\X``.)
|
||||
|
||||
It is *not* needed for ``b`` to be the total number of columns, nor for the
|
||||
sum of the fractions of the ``\X`` specifiers to add up to one. For example
|
||||
``|\X{2}{5}|\X{1}{5}|\X{1}{5}|`` is legitimate and the table will occupy
|
||||
80% of the line width, the first of its three columns having the same width
|
||||
as the sum of the next two.
|
||||
|
||||
This is used by the ``:widths:`` option of the :dudir:`table` directive.
|
||||
|
||||
Since Sphinx 1.6, there is also the ``\Y{f}`` specifier which admits a
|
||||
decimal argument, such has ``\Y{0.15}``: this would have the same effect as
|
||||
``\X{3}{20}``.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
|
||||
Merged cells from complex grid tables (either multi-row, multi-column, or
|
||||
both) now allow blockquotes, lists, literal blocks, ... as do regular cells.
|
||||
|
||||
Sphinx's merged cells interact well with ``p{width}``, ``\X{a}{b}``, ``Y{f}``
|
||||
and tabulary's columns.
|
||||
|
||||
Math
|
||||
----
|
||||
|
||||
See :ref:`math-support`.
|
||||
|
||||
.. rubric:: Footnotes
|
||||
|
||||
.. [#] For most builders name and format are the same. At the moment only
|
||||
builders derived from the html builder distinguish between the builder
|
||||
format and the builder name.
|
||||
|
||||
Note that the current builder tag is not available in ``conf.py``, it is
|
||||
only available after the builder is initialized.
|
||||
|
||||
@@ -1,253 +0,0 @@
|
||||
.. highlight:: rest
|
||||
|
||||
Paragraph-level markup
|
||||
----------------------
|
||||
|
||||
.. index:: note, warning
|
||||
pair: changes; in version
|
||||
|
||||
These directives create short paragraphs and can be used inside information
|
||||
units as well as normal text:
|
||||
|
||||
.. rst:directive:: .. note::
|
||||
|
||||
An especially important bit of information about an API that a user should be
|
||||
aware of when using whatever bit of API the note pertains to. The content of
|
||||
the directive should be written in complete sentences and include all
|
||||
appropriate punctuation.
|
||||
|
||||
Example::
|
||||
|
||||
.. note::
|
||||
|
||||
This function is not suitable for sending spam e-mails.
|
||||
|
||||
.. rst:directive:: .. warning::
|
||||
|
||||
An important bit of information about an API that a user should be very aware
|
||||
of when using whatever bit of API the warning pertains to. The content of
|
||||
the directive should be written in complete sentences and include all
|
||||
appropriate punctuation. This differs from :rst:dir:`note` in that it is
|
||||
recommended over :rst:dir:`note` for information regarding security.
|
||||
|
||||
.. rst:directive:: .. versionadded:: version
|
||||
|
||||
This directive documents the version of the project which added the described
|
||||
feature to the library or C API. When this applies to an entire module, it
|
||||
should be placed at the top of the module section before any prose.
|
||||
|
||||
The first argument must be given and is the version in question; you can add
|
||||
a second argument consisting of a *brief* explanation of the change.
|
||||
|
||||
Example::
|
||||
|
||||
.. versionadded:: 2.5
|
||||
The *spam* parameter.
|
||||
|
||||
Note that there must be no blank line between the directive head and the
|
||||
explanation; this is to make these blocks visually continuous in the markup.
|
||||
|
||||
.. rst:directive:: .. versionchanged:: version
|
||||
|
||||
Similar to :rst:dir:`versionadded`, but describes when and what changed in
|
||||
the named feature in some way (new parameters, changed side effects, etc.).
|
||||
|
||||
.. rst:directive:: .. deprecated:: version
|
||||
|
||||
Similar to :rst:dir:`versionchanged`, but describes when the feature was
|
||||
deprecated. An explanation can also be given, for example to inform the
|
||||
reader what should be used instead. Example::
|
||||
|
||||
.. deprecated:: 3.1
|
||||
Use :func:`spam` instead.
|
||||
|
||||
|
||||
--------------
|
||||
|
||||
.. rst:directive:: seealso
|
||||
|
||||
Many sections include a list of references to module documentation or
|
||||
external documents. These lists are created using the :rst:dir:`seealso`
|
||||
directive.
|
||||
|
||||
The :rst:dir:`seealso` directive is typically placed in a section just before
|
||||
any subsections. For the HTML output, it is shown boxed off from the main
|
||||
flow of the text.
|
||||
|
||||
The content of the :rst:dir:`seealso` directive should be a reST definition
|
||||
list. Example::
|
||||
|
||||
.. seealso::
|
||||
|
||||
Module :py:mod:`zipfile`
|
||||
Documentation of the :py:mod:`zipfile` standard module.
|
||||
|
||||
`GNU tar manual, Basic Tar Format <http://link>`_
|
||||
Documentation for tar archive files, including GNU tar extensions.
|
||||
|
||||
There's also a "short form" allowed that looks like this::
|
||||
|
||||
.. seealso:: modules :py:mod:`zipfile`, :py:mod:`tarfile`
|
||||
|
||||
.. versionadded:: 0.5
|
||||
The short form.
|
||||
|
||||
.. rst:directive:: .. rubric:: title
|
||||
|
||||
This directive creates a paragraph heading that is not used to create a
|
||||
table of contents node.
|
||||
|
||||
.. note::
|
||||
|
||||
If the *title* of the rubric is "Footnotes" (or the selected language's
|
||||
equivalent), this rubric is ignored by the LaTeX writer, since it is
|
||||
assumed to only contain footnote definitions and therefore would create an
|
||||
empty heading.
|
||||
|
||||
|
||||
.. rst:directive:: centered
|
||||
|
||||
This directive creates a centered boldfaced line of text. Use it as
|
||||
follows::
|
||||
|
||||
.. centered:: LICENSE AGREEMENT
|
||||
|
||||
.. deprecated:: 1.1
|
||||
This presentation-only directive is a legacy from older versions. Use a
|
||||
:rst:dir:`rst-class` directive instead and add an appropriate style.
|
||||
|
||||
|
||||
.. rst:directive:: hlist
|
||||
|
||||
This directive must contain a bullet list. It will transform it into a more
|
||||
compact list by either distributing more than one item horizontally, or
|
||||
reducing spacing between items, depending on the builder.
|
||||
|
||||
For builders that support the horizontal distribution, there is a ``columns``
|
||||
option that specifies the number of columns; it defaults to 2. Example::
|
||||
|
||||
.. hlist::
|
||||
:columns: 3
|
||||
|
||||
* A list of
|
||||
* short items
|
||||
* that should be
|
||||
* displayed
|
||||
* horizontally
|
||||
|
||||
.. versionadded:: 0.6
|
||||
|
||||
|
||||
Table-of-contents markup
|
||||
------------------------
|
||||
|
||||
The :rst:dir:`toctree` directive, which generates tables of contents of
|
||||
subdocuments, is described in :ref:`toctree-directive`.
|
||||
|
||||
For local tables of contents, use the standard reST :dudir:`contents directive
|
||||
<table-of-contents>`.
|
||||
|
||||
|
||||
.. _glossary-directive:
|
||||
|
||||
Glossary
|
||||
--------
|
||||
|
||||
.. rst:directive:: .. glossary::
|
||||
|
||||
This directive must contain a reST definition-list-like markup with terms and
|
||||
definitions. The definitions will then be referencable with the
|
||||
:rst:role:`term` role. Example::
|
||||
|
||||
.. glossary::
|
||||
|
||||
environment
|
||||
A structure where information about all documents under the root is
|
||||
saved, and used for cross-referencing. The environment is pickled
|
||||
after the parsing stage, so that successive runs only need to read
|
||||
and parse new and changed documents.
|
||||
|
||||
source directory
|
||||
The directory which, including its subdirectories, contains all
|
||||
source files for one Sphinx project.
|
||||
|
||||
In contrast to regular definition lists, *multiple* terms per entry are
|
||||
allowed, and inline markup is allowed in terms. You can link to all of the
|
||||
terms. For example::
|
||||
|
||||
.. glossary::
|
||||
|
||||
term 1
|
||||
term 2
|
||||
Definition of both terms.
|
||||
|
||||
(When the glossary is sorted, the first term determines the sort order.)
|
||||
|
||||
If you want to specify "grouping key" for general index entries, you can put a "key"
|
||||
as "term : key". For example::
|
||||
|
||||
.. glossary::
|
||||
|
||||
term 1 : A
|
||||
term 2 : B
|
||||
Definition of both terms.
|
||||
|
||||
Note that "key" is used for grouping key as is.
|
||||
The "key" isn't normalized; key "A" and "a" become different groups.
|
||||
The whole characters in "key" is used instead of a first character; it is used for
|
||||
"Combining Character Sequence" and "Surrogate Pairs" grouping key.
|
||||
|
||||
In i18n situation, you can specify "localized term : key" even if original text only
|
||||
have "term" part. In this case, translated "localized term" will be categorized in
|
||||
"key" group.
|
||||
|
||||
.. versionadded:: 0.6
|
||||
You can now give the glossary directive a ``:sorted:`` flag that will
|
||||
automatically sort the entries alphabetically.
|
||||
|
||||
.. versionchanged:: 1.1
|
||||
Now supports multiple terms and inline markup in terms.
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
Index key for glossary term should be considered *experimental*.
|
||||
|
||||
Grammar production displays
|
||||
---------------------------
|
||||
|
||||
Special markup is available for displaying the productions of a formal grammar.
|
||||
The markup is simple and does not attempt to model all aspects of BNF (or any
|
||||
derived forms), but provides enough to allow context-free grammars to be
|
||||
displayed in a way that causes uses of a symbol to be rendered as hyperlinks to
|
||||
the definition of the symbol. There is this directive:
|
||||
|
||||
.. rst:directive:: .. productionlist:: [name]
|
||||
|
||||
This directive is used to enclose a group of productions. Each production is
|
||||
given on a single line and consists of a name, separated by a colon from the
|
||||
following definition. If the definition spans multiple lines, each
|
||||
continuation line must begin with a colon placed at the same column as in the
|
||||
first line.
|
||||
|
||||
The argument to :rst:dir:`productionlist` serves to distinguish different
|
||||
sets of production lists that belong to different grammars.
|
||||
|
||||
Blank lines are not allowed within ``productionlist`` directive arguments.
|
||||
|
||||
The definition can contain token names which are marked as interpreted text
|
||||
(e.g. ``sum ::= `integer` "+" `integer```) -- this generates cross-references
|
||||
to the productions of these tokens. Outside of the production list, you can
|
||||
reference to token productions using :rst:role:`token`.
|
||||
|
||||
Note that no further reST parsing is done in the production, so that you
|
||||
don't have to escape ``*`` or ``|`` characters.
|
||||
|
||||
The following is an example taken from the Python Reference Manual::
|
||||
|
||||
.. productionlist::
|
||||
try_stmt: try1_stmt | try2_stmt
|
||||
try1_stmt: "try" ":" `suite`
|
||||
: ("except" [`expression` ["," `target`]] ":" `suite`)+
|
||||
: ["else" ":" `suite`]
|
||||
: ["finally" ":" `suite`]
|
||||
try2_stmt: "try" ":" `suite`
|
||||
: "finally" ":" `suite`
|
||||
@@ -1,242 +0,0 @@
|
||||
.. highlight:: rst
|
||||
.. _toctree-directive:
|
||||
|
||||
The TOC tree
|
||||
============
|
||||
|
||||
.. index:: pair: table of; contents
|
||||
|
||||
Since reST does not have facilities to interconnect several documents, or split
|
||||
documents into multiple output files, Sphinx uses a custom directive to add
|
||||
relations between the single files the documentation is made of, as well as
|
||||
tables of contents. The ``toctree`` directive is the central element.
|
||||
|
||||
.. note::
|
||||
|
||||
Simple "inclusion" of one file in another can be done with the
|
||||
:dudir:`include` directive.
|
||||
|
||||
.. rst:directive:: toctree
|
||||
|
||||
This directive inserts a "TOC tree" at the current location, using the
|
||||
individual TOCs (including "sub-TOC trees") of the documents given in the
|
||||
directive body. Relative document names (not beginning with a slash) are
|
||||
relative to the document the directive occurs in, absolute names are relative
|
||||
to the source directory. A numeric ``maxdepth`` option may be given to
|
||||
indicate the depth of the tree; by default, all levels are included. [#]_
|
||||
|
||||
Consider this example (taken from the Python docs' library reference index)::
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
intro
|
||||
strings
|
||||
datatypes
|
||||
numeric
|
||||
(many more documents listed here)
|
||||
|
||||
This accomplishes two things:
|
||||
|
||||
* Tables of contents from all those documents are inserted, with a maximum
|
||||
depth of two, that means one nested heading. ``toctree`` directives in
|
||||
those documents are also taken into account.
|
||||
* Sphinx knows the relative order of the documents ``intro``,
|
||||
``strings`` and so forth, and it knows that they are children of the shown
|
||||
document, the library index. From this information it generates "next
|
||||
chapter", "previous chapter" and "parent chapter" links.
|
||||
|
||||
**Entries**
|
||||
|
||||
Document titles in the :rst:dir:`toctree` will be automatically read from the
|
||||
title of the referenced document. If that isn't what you want, you can
|
||||
specify an explicit title and target using a similar syntax to reST
|
||||
hyperlinks (and Sphinx's :ref:`cross-referencing syntax <xref-syntax>`). This
|
||||
looks like::
|
||||
|
||||
.. toctree::
|
||||
|
||||
intro
|
||||
All about strings <strings>
|
||||
datatypes
|
||||
|
||||
The second line above will link to the ``strings`` document, but will use the
|
||||
title "All about strings" instead of the title of the ``strings`` document.
|
||||
|
||||
You can also add external links, by giving an HTTP URL instead of a document
|
||||
name.
|
||||
|
||||
**Section numbering**
|
||||
|
||||
If you want to have section numbers even in HTML output, give the
|
||||
**toplevel** toctree a ``numbered`` option. For example::
|
||||
|
||||
.. toctree::
|
||||
:numbered:
|
||||
|
||||
foo
|
||||
bar
|
||||
|
||||
Numbering then starts at the heading of ``foo``. Sub-toctrees are
|
||||
automatically numbered (don't give the ``numbered`` flag to those).
|
||||
|
||||
Numbering up to a specific depth is also possible, by giving the depth as a
|
||||
numeric argument to ``numbered``.
|
||||
|
||||
**Additional options**
|
||||
|
||||
You can use ``caption`` option to provide a toctree caption and you can use
|
||||
``name`` option to provide implicit target name that can be referenced by
|
||||
using :rst:role:`ref`::
|
||||
|
||||
.. toctree::
|
||||
:caption: Table of Contents
|
||||
:name: mastertoc
|
||||
|
||||
foo
|
||||
|
||||
If you want only the titles of documents in the tree to show up, not other
|
||||
headings of the same level, you can use the ``titlesonly`` option::
|
||||
|
||||
.. toctree::
|
||||
:titlesonly:
|
||||
|
||||
foo
|
||||
bar
|
||||
|
||||
You can use "globbing" in toctree directives, by giving the ``glob`` flag
|
||||
option. All entries are then matched against the list of available
|
||||
documents, and matches are inserted into the list alphabetically. Example::
|
||||
|
||||
.. toctree::
|
||||
:glob:
|
||||
|
||||
intro*
|
||||
recipe/*
|
||||
*
|
||||
|
||||
This includes first all documents whose names start with ``intro``, then all
|
||||
documents in the ``recipe`` folder, then all remaining documents (except the
|
||||
one containing the directive, of course.) [#]_
|
||||
|
||||
The special entry name ``self`` stands for the document containing the
|
||||
toctree directive. This is useful if you want to generate a "sitemap" from
|
||||
the toctree.
|
||||
|
||||
You can use the ``reversed`` flag option to reverse the order of the entries
|
||||
in the list. This can be useful when using the ``glob`` flag option to
|
||||
reverse the ordering of the files. Example::
|
||||
|
||||
.. toctree::
|
||||
:glob:
|
||||
:reversed:
|
||||
|
||||
recipe/*
|
||||
|
||||
You can also give a "hidden" option to the directive, like this::
|
||||
|
||||
.. toctree::
|
||||
:hidden:
|
||||
|
||||
doc_1
|
||||
doc_2
|
||||
|
||||
This will still notify Sphinx of the document hierarchy, but not insert links
|
||||
into the document at the location of the directive -- this makes sense if you
|
||||
intend to insert these links yourself, in a different style, or in the HTML
|
||||
sidebar.
|
||||
|
||||
In cases where you want to have only one top-level toctree and hide all other
|
||||
lower level toctrees you can add the "includehidden" option to the top-level
|
||||
toctree entry::
|
||||
|
||||
.. toctree::
|
||||
:includehidden:
|
||||
|
||||
doc_1
|
||||
doc_2
|
||||
|
||||
All other toctree entries can then be eliminated by the "hidden" option.
|
||||
|
||||
In the end, all documents in the :term:`source directory` (or subdirectories)
|
||||
must occur in some ``toctree`` directive; Sphinx will emit a warning if it
|
||||
finds a file that is not included, because that means that this file will not
|
||||
be reachable through standard navigation.
|
||||
|
||||
Use :confval:`exclude_patterns` to explicitly exclude documents or
|
||||
directories from building completely. Use :ref:`the "orphan" metadata
|
||||
<metadata>` to let a document be built, but notify Sphinx that it is not
|
||||
reachable via a toctree.
|
||||
|
||||
The "master document" (selected by :confval:`master_doc`) is the "root" of
|
||||
the TOC tree hierarchy. It can be used as the documentation's main page, or
|
||||
as a "full table of contents" if you don't give a ``maxdepth`` option.
|
||||
|
||||
.. versionchanged:: 0.3
|
||||
Added "globbing" option.
|
||||
|
||||
.. versionchanged:: 0.6
|
||||
Added "numbered" and "hidden" options as well as external links and
|
||||
support for "self" references.
|
||||
|
||||
.. versionchanged:: 1.0
|
||||
Added "titlesonly" option.
|
||||
|
||||
.. versionchanged:: 1.1
|
||||
Added numeric argument to "numbered".
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
Added "includehidden" option.
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
Added "caption" and "name" option.
|
||||
|
||||
Special names
|
||||
-------------
|
||||
|
||||
Sphinx reserves some document names for its own use; you should not try to
|
||||
create documents with these names -- it will cause problems.
|
||||
|
||||
The special document names (and pages generated for them) are:
|
||||
|
||||
* ``genindex``, ``modindex``, ``search``
|
||||
|
||||
These are used for the general index, the Python module index, and the search
|
||||
page, respectively.
|
||||
|
||||
The general index is populated with entries from modules, all index-generating
|
||||
:ref:`object descriptions <basic-domain-markup>`, and from :rst:dir:`index`
|
||||
directives.
|
||||
|
||||
The Python module index contains one entry per :rst:dir:`py:module` directive.
|
||||
|
||||
The search page contains a form that uses the generated JSON search index and
|
||||
JavaScript to full-text search the generated documents for search words; it
|
||||
should work on every major browser that supports modern JavaScript.
|
||||
|
||||
* every name beginning with ``_``
|
||||
|
||||
Though only few such names are currently used by Sphinx, you should not create
|
||||
documents or document-containing directories with such names. (Using ``_`` as
|
||||
a prefix for a custom template directory is fine.)
|
||||
|
||||
.. warning::
|
||||
|
||||
Be careful with unusual characters in filenames. Some formats may interpret
|
||||
these characters in unexpected ways:
|
||||
|
||||
* Do not use the colon ``:`` for HTML based formats. Links to other parts
|
||||
may not work.
|
||||
|
||||
* Do not use the plus ``+`` for the ePub format. Some resources may not be
|
||||
found.
|
||||
|
||||
.. rubric:: Footnotes
|
||||
|
||||
.. [#] The LaTeX writer only refers the ``maxdepth`` option of first toctree
|
||||
directive in the document.
|
||||
|
||||
.. [#] A note on available globbing syntax: you can use the standard shell
|
||||
constructs ``*``, ``?``, ``[...]`` and ``[!...]`` with the feature that
|
||||
these all don't match slashes. A double star ``**`` can be used to match
|
||||
any sequence of characters *including* slashes.
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 146 KiB |
+10
-3
@@ -62,7 +62,7 @@ following contents::
|
||||
|
||||
{% extends "!layout.html" %}
|
||||
{% block rootrellink %}
|
||||
<li><a href="http://project.invalid/">Project Homepage</a> »</li>
|
||||
<li><a href="https://project.invalid/">Project Homepage</a> »</li>
|
||||
{{ super() }}
|
||||
{% endblock %}
|
||||
|
||||
@@ -70,8 +70,8 @@ By prefixing the name of the overridden template with an exclamation mark,
|
||||
Sphinx will load the layout template from the underlying HTML theme.
|
||||
|
||||
**Important**: If you override a block, call ``{{ super() }}`` somewhere to
|
||||
render the block's content in the extended template -- unless you don't want
|
||||
that content to show up.
|
||||
render the block's original content in the extended template -- unless you
|
||||
don't want that content to show up.
|
||||
|
||||
|
||||
Working with the builtin templates
|
||||
@@ -200,6 +200,10 @@ Overriding works like this::
|
||||
|
||||
{% set script_files = script_files + ["_static/myscript.js"] %}
|
||||
|
||||
.. deprecated:: 1.8.0
|
||||
|
||||
Please use ``.Sphinx.add_js_file()`` instead.
|
||||
|
||||
Helper Functions
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
@@ -228,6 +232,9 @@ them to generate links or output multiply used elements.
|
||||
|
||||
Return the rendered relation bar.
|
||||
|
||||
.. function:: warning(message)
|
||||
|
||||
Emit a warning message.
|
||||
|
||||
Global Variables
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
+26
-274
@@ -1,10 +1,16 @@
|
||||
.. highlightlang:: python
|
||||
.. highlight:: python
|
||||
|
||||
HTML theming support
|
||||
====================
|
||||
|
||||
.. versionadded:: 0.6
|
||||
|
||||
.. note::
|
||||
|
||||
This document provides information about creating your own theme. If you
|
||||
simply wish to use a pre-existing HTML themes, refer to
|
||||
:doc:`/usage/theming`.
|
||||
|
||||
Sphinx supports changing the appearance of its HTML output via *themes*. A
|
||||
theme is a collection of HTML templates, stylesheet(s) and other static files.
|
||||
Additionally, it has a configuration file which specifies from which theme to
|
||||
@@ -15,248 +21,13 @@ Themes are meant to be project-unaware, so they can be used for different
|
||||
projects without change.
|
||||
|
||||
|
||||
Using a theme
|
||||
-------------
|
||||
|
||||
Using an existing theme is easy. If the theme is builtin to Sphinx, you only
|
||||
need to set the :confval:`html_theme` config value. With the
|
||||
:confval:`html_theme_options` config value you can set theme-specific options
|
||||
that change the look and feel. For example, you could have the following in
|
||||
your :file:`conf.py`::
|
||||
|
||||
html_theme = "classic"
|
||||
html_theme_options = {
|
||||
"rightsidebar": "true",
|
||||
"relbarbgcolor": "black"
|
||||
}
|
||||
|
||||
That would give you the classic theme, but with a sidebar on the right side and
|
||||
a black background for the relation bar (the bar with the navigation links at
|
||||
the page's top and bottom).
|
||||
|
||||
If the theme does not come with Sphinx, it can be in two static forms: either a
|
||||
directory (containing :file:`theme.conf` and other needed files), or a zip file
|
||||
with the same contents. Either of them must be put where Sphinx can find it;
|
||||
for this there is the config value :confval:`html_theme_path`. It gives a list
|
||||
of directories, relative to the directory containing :file:`conf.py`, that can
|
||||
contain theme directories or zip files. For example, if you have a theme in the
|
||||
file :file:`blue.zip`, you can put it right in the directory containing
|
||||
:file:`conf.py` and use this configuration::
|
||||
|
||||
html_theme = "blue"
|
||||
html_theme_path = ["."]
|
||||
|
||||
The third form is a python package. If a theme you want to use is distributed
|
||||
as a python package, you can use it after installing
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# installing theme package
|
||||
$ pip install sphinxjp.themes.dotted
|
||||
|
||||
# use it in your conf.py
|
||||
html_theme = "dotted"
|
||||
|
||||
|
||||
.. _builtin-themes:
|
||||
|
||||
Builtin themes
|
||||
--------------
|
||||
|
||||
.. cssclass:: longtable
|
||||
|
||||
+--------------------+--------------------+
|
||||
| **Theme overview** | |
|
||||
+--------------------+--------------------+
|
||||
| |alabaster| | |classic| |
|
||||
| | |
|
||||
| *alabaster* | *classic* |
|
||||
+--------------------+--------------------+
|
||||
| |sphinxdoc| | |scrolls| |
|
||||
| | |
|
||||
| *sphinxdoc* | *scrolls* |
|
||||
+--------------------+--------------------+
|
||||
| |agogo| | |traditional| |
|
||||
| | |
|
||||
| *agogo* | *traditional* |
|
||||
+--------------------+--------------------+
|
||||
| |nature| | |haiku| |
|
||||
| | |
|
||||
| *nature* | *haiku* |
|
||||
+--------------------+--------------------+
|
||||
| |pyramid| | |bizstyle| |
|
||||
| | |
|
||||
| *pyramid* | *bizstyle* |
|
||||
+--------------------+--------------------+
|
||||
|
||||
.. |alabaster| image:: themes/alabaster.png
|
||||
.. |classic| image:: themes/classic.png
|
||||
.. |sphinxdoc| image:: themes/sphinxdoc.png
|
||||
.. |scrolls| image:: themes/scrolls.png
|
||||
.. |agogo| image:: themes/agogo.png
|
||||
.. |traditional| image:: themes/traditional.png
|
||||
.. |nature| image:: themes/nature.png
|
||||
.. |haiku| image:: themes/haiku.png
|
||||
.. |pyramid| image:: themes/pyramid.png
|
||||
.. |bizstyle| image:: themes/bizstyle.png
|
||||
|
||||
Sphinx comes with a selection of themes to choose from.
|
||||
|
||||
.. cssclass:: clear
|
||||
|
||||
These themes are:
|
||||
|
||||
* **basic** -- This is a basically unstyled layout used as the base for the
|
||||
other themes, and usable as the base for custom themes as well. The HTML
|
||||
contains all important elements like sidebar and relation bar. There are
|
||||
these options (which are inherited by the other themes):
|
||||
|
||||
- **nosidebar** (true or false): Don't include the sidebar. Defaults to
|
||||
``False``.
|
||||
|
||||
- **sidebarwidth** (an integer): Width of the sidebar in pixels. (Do not
|
||||
include ``px`` in the value.) Defaults to 230 pixels.
|
||||
|
||||
* **alabaster** -- `Alabaster theme`_ is a modified "Kr" Sphinx theme from @kennethreitz
|
||||
(especially as used in his Requests project), which was itself originally based on
|
||||
@mitsuhiko's theme used for Flask & related projects.
|
||||
Check out at its `installation page`_ how to set up properly
|
||||
:confval:`html_sidebars` for its use.
|
||||
|
||||
.. _Alabaster theme: https://pypi.python.org/pypi/alabaster
|
||||
.. _installation page: http://alabaster.readthedocs.io/en/latest/installation.html
|
||||
|
||||
* **classic** -- This is the classic theme, which looks like `the Python 2
|
||||
documentation <https://docs.python.org/2/>`_. It can be customized via
|
||||
these options:
|
||||
|
||||
- **rightsidebar** (true or false): Put the sidebar on the right side.
|
||||
Defaults to ``False``.
|
||||
|
||||
- **stickysidebar** (true or false): Make the sidebar "fixed" so that it
|
||||
doesn't scroll out of view for long body content. This may not work well
|
||||
with all browsers. Defaults to ``False``.
|
||||
|
||||
- **collapsiblesidebar** (true or false): Add an *experimental* JavaScript
|
||||
snippet that makes the sidebar collapsible via a button on its side.
|
||||
*Doesn't work with "stickysidebar".* Defaults to ``False``.
|
||||
|
||||
- **externalrefs** (true or false): Display external links differently from
|
||||
internal links. Defaults to ``False``.
|
||||
|
||||
There are also various color and font options that can change the color scheme
|
||||
without having to write a custom stylesheet:
|
||||
|
||||
- **footerbgcolor** (CSS color): Background color for the footer line.
|
||||
- **footertextcolor** (CSS color): Text color for the footer line.
|
||||
- **sidebarbgcolor** (CSS color): Background color for the sidebar.
|
||||
- **sidebarbtncolor** (CSS color): Background color for the sidebar collapse
|
||||
button (used when *collapsiblesidebar* is ``True``).
|
||||
- **sidebartextcolor** (CSS color): Text color for the sidebar.
|
||||
- **sidebarlinkcolor** (CSS color): Link color for the sidebar.
|
||||
- **relbarbgcolor** (CSS color): Background color for the relation bar.
|
||||
- **relbartextcolor** (CSS color): Text color for the relation bar.
|
||||
- **relbarlinkcolor** (CSS color): Link color for the relation bar.
|
||||
- **bgcolor** (CSS color): Body background color.
|
||||
- **textcolor** (CSS color): Body text color.
|
||||
- **linkcolor** (CSS color): Body link color.
|
||||
- **visitedlinkcolor** (CSS color): Body color for visited links.
|
||||
- **headbgcolor** (CSS color): Background color for headings.
|
||||
- **headtextcolor** (CSS color): Text color for headings.
|
||||
- **headlinkcolor** (CSS color): Link color for headings.
|
||||
- **codebgcolor** (CSS color): Background color for code blocks.
|
||||
- **codetextcolor** (CSS color): Default text color for code blocks, if not
|
||||
set differently by the highlighting style.
|
||||
|
||||
- **bodyfont** (CSS font-family): Font for normal text.
|
||||
- **headfont** (CSS font-family): Font for headings.
|
||||
|
||||
* **sphinxdoc** -- The theme used for this documentation. It features a sidebar
|
||||
on the right side. There are currently no options beyond *nosidebar* and
|
||||
*sidebarwidth*.
|
||||
|
||||
* **scrolls** -- A more lightweight theme, based on `the Jinja documentation
|
||||
<http://jinja.pocoo.org/>`_. The following color options are available:
|
||||
|
||||
- **headerbordercolor**
|
||||
- **subheadlinecolor**
|
||||
- **linkcolor**
|
||||
- **visitedlinkcolor**
|
||||
- **admonitioncolor**
|
||||
|
||||
* **agogo** -- A theme created by Andi Albrecht. The following options are
|
||||
supported:
|
||||
|
||||
- **bodyfont** (CSS font family): Font for normal text.
|
||||
- **headerfont** (CSS font family): Font for headings.
|
||||
- **pagewidth** (CSS length): Width of the page content, default 70em.
|
||||
- **documentwidth** (CSS length): Width of the document (without sidebar),
|
||||
default 50em.
|
||||
- **sidebarwidth** (CSS length): Width of the sidebar, default 20em.
|
||||
- **bgcolor** (CSS color): Background color.
|
||||
- **headerbg** (CSS value for "background"): background for the header area,
|
||||
default a grayish gradient.
|
||||
- **footerbg** (CSS value for "background"): background for the footer area,
|
||||
default a light gray gradient.
|
||||
- **linkcolor** (CSS color): Body link color.
|
||||
- **headercolor1**, **headercolor2** (CSS color): colors for <h1> and <h2>
|
||||
headings.
|
||||
- **headerlinkcolor** (CSS color): Color for the backreference link in
|
||||
headings.
|
||||
- **textalign** (CSS *text-align* value): Text alignment for the body, default
|
||||
is ``justify``.
|
||||
|
||||
* **nature** -- A greenish theme. There are currently no options beyond
|
||||
*nosidebar* and *sidebarwidth*.
|
||||
|
||||
* **pyramid** -- A theme from the Pyramid web framework project, designed by
|
||||
Blaise Laflamme. There are currently no options beyond *nosidebar* and
|
||||
*sidebarwidth*.
|
||||
|
||||
* **haiku** -- A theme without sidebar inspired by the `Haiku OS user guide
|
||||
<https://www.haiku-os.org/docs/userguide/en/contents.html>`_. The following
|
||||
options are supported:
|
||||
|
||||
- **full_logo** (true or false, default ``False``): If this is true, the
|
||||
header will only show the :confval:`html_logo`. Use this for large logos.
|
||||
If this is false, the logo (if present) will be shown floating right, and
|
||||
the documentation title will be put in the header.
|
||||
- **textcolor**, **headingcolor**, **linkcolor**, **visitedlinkcolor**,
|
||||
**hoverlinkcolor** (CSS colors): Colors for various body elements.
|
||||
|
||||
* **traditional** -- A theme resembling the old Python documentation. There are
|
||||
currently no options beyond *nosidebar* and *sidebarwidth*.
|
||||
|
||||
* **epub** -- A theme for the epub builder. This theme tries to save visual
|
||||
space which is a sparse resource on ebook readers. The following options
|
||||
are supported:
|
||||
|
||||
- **relbar1** (true or false, default ``True``): If this is true, the
|
||||
`relbar1` block is inserted in the epub output, otherwise it is omitted.
|
||||
- **footer** (true or false, default ``True``): If this is true, the
|
||||
`footer` block is inserted in the epub output, otherwise it is omitted.
|
||||
|
||||
- **bizstyle** -- A simple bluish theme. The following options are supported
|
||||
beyond *nosidebar* and *sidebarwidth*:
|
||||
|
||||
- **rightsidebar** (true or false): Put the sidebar on the right side.
|
||||
Defaults to ``False``.
|
||||
|
||||
.. versionadded:: 1.3
|
||||
'alabaster', 'sphinx_rtd_theme' and 'bizstyle' theme.
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
The 'default' theme has been renamed to 'classic'. 'default' is still
|
||||
available, however it will emit a notice that it is an alias for the new
|
||||
'alabaster' theme.
|
||||
|
||||
Creating themes
|
||||
---------------
|
||||
|
||||
As said, themes are either a directory or a zipfile (whose name is the theme
|
||||
name), containing the following:
|
||||
Themes take the form of either a directory or a zipfile (whose name is the
|
||||
theme name), containing the following:
|
||||
|
||||
* A :file:`theme.conf` file, see below.
|
||||
* A :file:`theme.conf` file.
|
||||
* HTML templates, if needed.
|
||||
* A ``static/`` directory containing any static files that will be copied to the
|
||||
output static directory on build. These can be images, styles, script files.
|
||||
@@ -270,6 +41,7 @@ Python :mod:`ConfigParser` module) and has the following structure:
|
||||
inherit = base theme
|
||||
stylesheet = main CSS name
|
||||
pygments_style = stylename
|
||||
sidebars = localtoc.html, relations.html, sourcelink.html, searchbox.html
|
||||
|
||||
[options]
|
||||
variable = default value
|
||||
@@ -289,21 +61,28 @@ Python :mod:`ConfigParser` module) and has the following structure:
|
||||
highlighting. This can be overridden by the user in the
|
||||
:confval:`pygments_style` config value.
|
||||
|
||||
* The **sidebars** setting gives the comma separated list of sidebar templates
|
||||
for constructing sidebars. This can be overridden by the user in the
|
||||
:confval:`html_sidebars` config value.
|
||||
|
||||
* The **options** section contains pairs of variable names and default values.
|
||||
These options can be overridden by the user in :confval:`html_theme_options`
|
||||
and are accessible from all templates as ``theme_<name>``.
|
||||
|
||||
.. versionadded:: 1.7
|
||||
sidebar settings
|
||||
|
||||
|
||||
.. _distribute-your-theme:
|
||||
|
||||
Distribute your theme as a python package
|
||||
Distribute your theme as a Python package
|
||||
-----------------------------------------
|
||||
|
||||
As a way to distribute your theme, you can use python package. Python package
|
||||
As a way to distribute your theme, you can use Python package. Python package
|
||||
brings to users easy setting up ways.
|
||||
|
||||
To distribute your theme as a python package, please define an entry point
|
||||
called ``sphinx.html_themes`` in your setup.py file, and write a ``setup()``
|
||||
To distribute your theme as a Python package, please define an entry point
|
||||
called ``sphinx.html_themes`` in your ``setup.py`` file, and write a ``setup()``
|
||||
function to register your themes using ``add_html_theme()`` API in it::
|
||||
|
||||
# 'setup.py'
|
||||
@@ -323,9 +102,8 @@ function to register your themes using ``add_html_theme()`` API in it::
|
||||
def setup(app):
|
||||
app.add_html_theme('name_of_theme', path.abspath(path.dirname(__file__)))
|
||||
|
||||
|
||||
If your theme package contains two or more themes, please call ``add_html_theme()``
|
||||
twice or more.
|
||||
If your theme package contains two or more themes, please call
|
||||
``add_html_theme()`` twice or more.
|
||||
|
||||
.. versionadded:: 1.2
|
||||
'sphinx_themes' entry_points feature.
|
||||
@@ -336,8 +114,9 @@ twice or more.
|
||||
.. versionadded:: 1.6
|
||||
``sphinx.html_themes`` entry_points feature.
|
||||
|
||||
|
||||
Templating
|
||||
~~~~~~~~~~
|
||||
----------
|
||||
|
||||
The :doc:`guide to templating <templating>` is helpful if you want to write your
|
||||
own templates. What is important to keep in mind is the order in which Sphinx
|
||||
@@ -352,7 +131,6 @@ name as an explicit directory: ``{% extends "basic/layout.html" %}``. From a
|
||||
user ``templates_path`` template, you can still use the "exclamation mark"
|
||||
syntax as described in the templating document.
|
||||
|
||||
|
||||
Static templates
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
@@ -369,32 +147,6 @@ templating to put the color options into the stylesheet. When a documentation
|
||||
is built with the classic theme, the output directory will contain a
|
||||
``_static/classic.css`` file where all template tags have been processed.
|
||||
|
||||
|
||||
.. [1] It is not an executable Python file, as opposed to :file:`conf.py`,
|
||||
because that would pose an unnecessary security risk if themes are
|
||||
shared.
|
||||
|
||||
Third Party Themes
|
||||
------------------
|
||||
|
||||
.. cssclass:: longtable
|
||||
|
||||
+--------------------+--------------------+
|
||||
| **Theme overview** | |
|
||||
+--------------------+--------------------+
|
||||
| |sphinx_rtd_theme| | |
|
||||
| | |
|
||||
| *sphinx_rtd_theme* | |
|
||||
+--------------------+--------------------+
|
||||
|
||||
.. |sphinx_rtd_theme| image:: themes/sphinx_rtd_theme.png
|
||||
|
||||
* **sphinx_rtd_theme** -- `Read the Docs Sphinx Theme`_.
|
||||
This is a mobile-friendly sphinx theme that was made for readthedocs.org.
|
||||
View a working demo over on readthedocs.org. You can get install and options
|
||||
information at `Read the Docs Sphinx Theme`_ page.
|
||||
|
||||
.. _Read the Docs Sphinx Theme: https://pypi.python.org/pypi/sphinx_rtd_theme
|
||||
|
||||
.. versionchanged:: 1.4
|
||||
**sphinx_rtd_theme** has become optional.
|
||||
@@ -9,11 +9,11 @@ Complementary to translations provided for Sphinx-generated messages such as
|
||||
navigation bars, Sphinx provides mechanisms facilitating *document* translations
|
||||
in itself. See the :ref:`intl-options` for details on configuration.
|
||||
|
||||
.. figure:: translation.png
|
||||
.. figure:: /_static/translation.png
|
||||
:width: 100%
|
||||
|
||||
Workflow visualization of translations in Sphinx. (The stick-figure is taken
|
||||
from an `XKCD comic <http://xkcd.com/779/>`_.)
|
||||
from an `XKCD comic <https://xkcd.com/779/>`_.)
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
@@ -46,14 +46,14 @@ They can be delivered to translators which will transform them to ``.po`` files
|
||||
--- so called **message catalogs** --- containing a mapping from the original
|
||||
messages to foreign-language strings.
|
||||
|
||||
Gettext compiles them into a binary format known as **binary catalogs** through
|
||||
:program:`msgfmt` for efficiency reasons. If you make these files discoverable
|
||||
with :confval:`locale_dirs` for your :confval:`language`, Sphinx will pick them
|
||||
up automatically.
|
||||
*gettext* compiles them into a binary format known as **binary catalogs**
|
||||
through :program:`msgfmt` for efficiency reasons. If you make these files
|
||||
discoverable with :confval:`locale_dirs` for your :confval:`language`, Sphinx
|
||||
will pick them up automatically.
|
||||
|
||||
An example: you have a document ``usage.rst`` in your Sphinx project. The
|
||||
gettext builder will put its messages into ``usage.pot``. Imagine you have
|
||||
Spanish translations [2]_ on your hands in ``usage.po`` --- for your builds to
|
||||
*gettext* builder will put its messages into ``usage.pot``. Imagine you have
|
||||
Spanish translations [2]_ stored in ``usage.po`` --- for your builds to
|
||||
be translated you need to follow these instructions:
|
||||
|
||||
* Compile your message catalog to a locale directory, say ``locale``, so it
|
||||
@@ -63,7 +63,8 @@ be translated you need to follow these instructions:
|
||||
msgfmt "usage.po" -o "locale/es/LC_MESSAGES/usage.mo"
|
||||
|
||||
* Set :confval:`locale_dirs` to ``["locale/"]``.
|
||||
* Set :confval:`language` to ``es`` (also possible via :option:`-D <sphinx-build -D>`).
|
||||
* Set :confval:`language` to ``es`` (also possible via
|
||||
:option:`-D <sphinx-build -D>`).
|
||||
* Run your desired build.
|
||||
|
||||
|
||||
@@ -71,103 +72,124 @@ Translating with sphinx-intl
|
||||
----------------------------
|
||||
|
||||
Quick guide
|
||||
^^^^^^^^^^^
|
||||
~~~~~~~~~~~
|
||||
|
||||
`sphinx-intl`_ is a useful tool to work with Sphinx translation flow.
|
||||
This section describe an easy way to translate with sphinx-intl.
|
||||
`sphinx-intl`_ is a useful tool to work with Sphinx translation flow. This
|
||||
section describe an easy way to translate with *sphinx-intl*.
|
||||
|
||||
#. Install `sphinx-intl`_ by :command:`pip install sphinx-intl` or
|
||||
:command:`easy_install sphinx-intl`.
|
||||
#. Install `sphinx-intl`_.
|
||||
|
||||
#. Add configurations to your `conf.py`::
|
||||
.. code-block:: console
|
||||
|
||||
$ pip install sphinx-intl
|
||||
|
||||
#. Add configurations to ``conf.py``.
|
||||
|
||||
::
|
||||
|
||||
locale_dirs = ['locale/'] # path is example but recommended.
|
||||
gettext_compact = False # optional.
|
||||
|
||||
This case-study assumes that :confval:`locale_dirs` is set to 'locale/' and
|
||||
:confval:`gettext_compact` is set to `False` (the Sphinx document is
|
||||
This case-study assumes that :confval:`locale_dirs` is set to ``locale/`` and
|
||||
:confval:`gettext_compact` is set to ``False`` (the Sphinx document is
|
||||
already configured as such).
|
||||
|
||||
#. Extract document's translatable messages into pot files:
|
||||
#. Extract translatable messages into pot files.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ make gettext
|
||||
|
||||
As a result, many pot files are generated under ``_build/gettext``
|
||||
directory.
|
||||
The generated pot files will be placed in the ``_build/gettext`` directory.
|
||||
|
||||
#. Setup/Update your `locale_dir`:
|
||||
#. Generate po files.
|
||||
|
||||
We'll use the pot files generated in the above step.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ sphinx-intl update -p _build/gettext -l de -l ja
|
||||
|
||||
Done. You got these directories that contain po files:
|
||||
Once completed, the generated po files will be placed in the below
|
||||
directories:
|
||||
|
||||
* `./locale/de/LC_MESSAGES/`
|
||||
* `./locale/ja/LC_MESSAGES/`
|
||||
* ``./locale/de/LC_MESSAGES/``
|
||||
* ``./locale/ja/LC_MESSAGES/``
|
||||
|
||||
#. Translate your po files under `./locale/<lang>/LC_MESSAGES/`.
|
||||
#. Translate po files.
|
||||
|
||||
#. make translated document.
|
||||
AS noted above, these are located in the ``./locale/<lang>/LC_MESSAGES``
|
||||
directory. An example of one such file, from Sphinx, ``builders.po``, is
|
||||
given below.
|
||||
|
||||
.. code-block:: po
|
||||
|
||||
# a5600c3d2e3d48fc8c261ea0284db79b
|
||||
#: ../../builders.rst:4
|
||||
msgid "Available builders"
|
||||
msgstr "<FILL HERE BY TARGET LANGUAGE>"
|
||||
|
||||
Another case, msgid is multi-line text and contains reStructuredText syntax:
|
||||
|
||||
.. code-block:: po
|
||||
|
||||
# 302558364e1d41c69b3277277e34b184
|
||||
#: ../../builders.rst:9
|
||||
msgid ""
|
||||
"These are the built-in Sphinx builders. More builders can be added by "
|
||||
":ref:`extensions <extensions>`."
|
||||
msgstr ""
|
||||
"FILL HERE BY TARGET LANGUAGE FILL HERE BY TARGET LANGUAGE FILL HERE "
|
||||
"BY TARGET LANGUAGE :ref:`EXTENSIONS <extensions>` FILL HERE."
|
||||
|
||||
Please be careful not to break reST notation. Most po-editors will help you
|
||||
with that.
|
||||
|
||||
#. Build translated document.
|
||||
|
||||
You need a :confval:`language` parameter in ``conf.py`` or you may also
|
||||
specify the parameter on the command line:
|
||||
specify the parameter on the command line.
|
||||
|
||||
For for BSD/GNU make, run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ make -e SPHINXOPTS="-D language='de'" html
|
||||
|
||||
For Windows :command:`cmd.exe`, run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> set SPHINXOPTS=-D language=de
|
||||
> .\make.bat html
|
||||
|
||||
For PowerShell, run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
> Set-Item env:SPHINXOPTS "-D language=de"
|
||||
> .\make.bat html
|
||||
|
||||
Congratulations! You got the translated documentation in the ``_build/html``
|
||||
directory.
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
sphinx-build that is invoked by make command will build po files into mo files.
|
||||
|
||||
If you are using 1.2.x or earlier, please invoke ``sphinx-intl build`` command
|
||||
before make command.
|
||||
:program:`sphinx-build` that is invoked by make command will build po files
|
||||
into mo files.
|
||||
|
||||
If you are using 1.2.x or earlier, please invoke :command:`sphinx-intl build`
|
||||
command before :command:`make` command.
|
||||
|
||||
Translating
|
||||
^^^^^^^^^^^
|
||||
|
||||
Translate po file under ``./locale/de/LC_MESSAGES`` directory.
|
||||
The case of builders.po file for sphinx document:
|
||||
|
||||
.. code-block:: po
|
||||
|
||||
# a5600c3d2e3d48fc8c261ea0284db79b
|
||||
#: ../../builders.rst:4
|
||||
msgid "Available builders"
|
||||
msgstr "<FILL HERE BY TARGET LANGUAGE>"
|
||||
|
||||
Another case, msgid is multi-line text and contains reStructuredText
|
||||
syntax:
|
||||
|
||||
.. code-block:: po
|
||||
|
||||
# 302558364e1d41c69b3277277e34b184
|
||||
#: ../../builders.rst:9
|
||||
msgid ""
|
||||
"These are the built-in Sphinx builders. More builders can be added by "
|
||||
":ref:`extensions <extensions>`."
|
||||
msgstr ""
|
||||
"FILL HERE BY TARGET LANGUAGE FILL HERE BY TARGET LANGUAGE FILL HERE "
|
||||
"BY TARGET LANGUAGE :ref:`EXTENSIONS <extensions>` FILL HERE."
|
||||
|
||||
Please be careful not to break reST notation. Most po-editors will help you
|
||||
with that.
|
||||
|
||||
~~~~~~~~~~~
|
||||
|
||||
Update your po files by new pot files
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If a document is updated, it is necessary to generate updated pot files
|
||||
and to apply differences to translated po files.
|
||||
In order to apply the updating difference of a pot file to po file,
|
||||
use the :command:`sphinx-intl update` command.
|
||||
If a document is updated, it is necessary to generate updated pot files and to
|
||||
apply differences to translated po files. In order to apply the updates from a
|
||||
pot file to the po file, use the :command:`sphinx-intl update` command.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
@@ -184,7 +206,7 @@ easy to fetch and push translations.
|
||||
.. TODO: why use transifex?
|
||||
|
||||
|
||||
#. Install `transifex-client`_
|
||||
#. Install `transifex-client`_.
|
||||
|
||||
You need :command:`tx` command to upload resources (pot files).
|
||||
|
||||
@@ -192,10 +214,9 @@ easy to fetch and push translations.
|
||||
|
||||
$ pip install transifex-client
|
||||
|
||||
.. seealso:: `Transifex Client v0.8 — Transifex documentation`_
|
||||
.. seealso:: `Transifex Client documentation`_
|
||||
|
||||
|
||||
#. Create your transifex_ account and create new project for your document
|
||||
#. Create your transifex_ account and create new project for your document.
|
||||
|
||||
Currently, transifex does not allow for a translation project to have more
|
||||
than one version of the document, so you'd better include a version number in
|
||||
@@ -206,8 +227,7 @@ easy to fetch and push translations.
|
||||
:Project ID: ``sphinx-document-test_1_0``
|
||||
:Project URL: ``https://www.transifex.com/projects/p/sphinx-document-test_1_0/``
|
||||
|
||||
|
||||
#. Create config files for tx command
|
||||
#. Create config files for :command:`tx` command.
|
||||
|
||||
This process will create ``.tx/config`` in the current directory, as well as
|
||||
a ``~/.transifexrc`` file that includes auth information.
|
||||
@@ -223,7 +243,7 @@ easy to fetch and push translations.
|
||||
...
|
||||
Done.
|
||||
|
||||
#. Upload pot files to transifex service
|
||||
#. Upload pot files to transifex service.
|
||||
|
||||
Register pot files to ``.tx/config`` file:
|
||||
|
||||
@@ -244,15 +264,14 @@ easy to fetch and push translations.
|
||||
...
|
||||
Done.
|
||||
|
||||
|
||||
#. Forward the translation on transifex
|
||||
#. Forward the translation on transifex.
|
||||
|
||||
.. TODO: write this section
|
||||
|
||||
#. Pull translated po files and make translated HTML.
|
||||
|
||||
#. Pull translated po files and make translated html
|
||||
|
||||
Get translated catalogs and build mo files (ex. for 'de'):
|
||||
Get translated catalogs and build mo files. For example, to build mo files
|
||||
for German (de):
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
@@ -263,52 +282,47 @@ easy to fetch and push translations.
|
||||
...
|
||||
Done.
|
||||
|
||||
Invoke make html:
|
||||
Invoke :command:`make html` (for BSD/GNU make):
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ make -e SPHINXOPTS="-D language='de'" html
|
||||
|
||||
|
||||
That's all!
|
||||
|
||||
|
||||
.. tip:: Translating locally and on Transifex
|
||||
|
||||
If you want to push all language's po files, you can be done by using
|
||||
:command:`tx push -t` command.
|
||||
Watch out! This operation overwrites translations in transifex.
|
||||
:command:`tx push -t` command. Watch out! This operation overwrites
|
||||
translations in transifex.
|
||||
|
||||
In other words, if you have updated each in the service and local po files,
|
||||
it would take much time and effort to integrate them.
|
||||
|
||||
|
||||
|
||||
Contributing to Sphinx reference translation
|
||||
--------------------------------------------
|
||||
|
||||
The recommended way for new contributors to translate Sphinx reference
|
||||
is to join the translation team on Transifex.
|
||||
The recommended way for new contributors to translate Sphinx reference is to
|
||||
join the translation team on Transifex.
|
||||
|
||||
There is `sphinx translation page`_ for Sphinx-1.3 documentation.
|
||||
There is `sphinx translation page`_ for Sphinx (master) documentation.
|
||||
|
||||
1. Login to transifex_ service.
|
||||
2. Go to `sphinx translation page`_.
|
||||
3. Click ``Request language`` and fill form.
|
||||
4. Wait acceptance by transifex sphinx translation maintainers.
|
||||
5. (after acceptance) translate on transifex.
|
||||
|
||||
5. (After acceptance) Translate on transifex.
|
||||
|
||||
.. rubric:: Footnotes
|
||||
|
||||
.. [1] See the `GNU gettext utilities
|
||||
<http://www.gnu.org/software/gettext/manual/gettext.html#Introduction>`_
|
||||
<https://www.gnu.org/software/gettext/manual/gettext.html#Introduction>`_
|
||||
for details on that software suite.
|
||||
.. [2] Because nobody expects the Spanish Inquisition!
|
||||
|
||||
|
||||
.. _`transifex-client`: https://pypi.python.org/pypi/transifex-client
|
||||
.. _`sphinx-intl`: https://pypi.python.org/pypi/sphinx-intl
|
||||
.. _`transifex-client`: https://pypi.org/project/transifex-client/
|
||||
.. _`sphinx-intl`: https://pypi.org/project/sphinx-intl/
|
||||
.. _Transifex: https://www.transifex.com/
|
||||
.. _`sphinx translation page`: https://www.transifex.com/sphinx-doc/sphinx-doc-1_3/
|
||||
.. _`Transifex Client v0.8 — Transifex documentation`: http://docs.transifex.com/developer/client/
|
||||
.. _`sphinx translation page`: https://www.transifex.com/sphinx-doc/sphinx-doc/
|
||||
.. _`Transifex Client documentation`: https://docs.transifex.com/client/introduction/
|
||||
@@ -32,15 +32,23 @@ For instance, from ``setup.py``::
|
||||
'build_sphinx': {
|
||||
'project': ('setup.py', name),
|
||||
'version': ('setup.py', version),
|
||||
'release': ('setup.py', release)}},
|
||||
'release': ('setup.py', release),
|
||||
'source_dir': ('setup.py', 'doc')}},
|
||||
)
|
||||
|
||||
.. note::
|
||||
|
||||
If you set Sphinx options directly in the ``setup()`` command, replace
|
||||
hyphens in variable names with underscores. In the example above,
|
||||
``source-dir`` becomes ``source_dir``.
|
||||
|
||||
Or add this section in ``setup.cfg``::
|
||||
|
||||
[build_sphinx]
|
||||
project = 'My project'
|
||||
version = 1.2
|
||||
release = 1.2.0
|
||||
source-dir = 'doc'
|
||||
|
||||
Once configured, call this by calling the relevant command on ``setup.py``::
|
||||
|
||||
@@ -54,7 +62,7 @@ Options for setuptools integration
|
||||
A boolean that determines whether the saved environment should be discarded
|
||||
on build. Default is false.
|
||||
|
||||
This can also be set by passing the `-E` flag to ``setup.py``.
|
||||
This can also be set by passing the `-E` flag to ``setup.py``:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@@ -74,7 +82,9 @@ Options for setuptools integration
|
||||
.. confval:: source-dir
|
||||
|
||||
The target source directory. This can be relative to the ``setup.py`` or
|
||||
``setup.cfg`` file, or it can be absolute. Default is ``''``.
|
||||
``setup.cfg`` file, or it can be absolute. It defaults to ``./doc`` or
|
||||
``./docs`` if either contains a file named ``conf.py`` (checking ``./doc``
|
||||
first); otherwise it defaults to the current directory.
|
||||
|
||||
This can also be set by passing the `-s` flag to ``setup.py``:
|
||||
|
||||
@@ -85,13 +95,13 @@ Options for setuptools integration
|
||||
.. confval:: build-dir
|
||||
|
||||
The target build directory. This can be relative to the ``setup.py`` or
|
||||
``setup.cfg`` file, or it can be absolute. Default is ``''``.
|
||||
``setup.cfg`` file, or it can be absolute. Default is ``./build/sphinx``.
|
||||
|
||||
.. confval:: config-dir
|
||||
|
||||
Location of the configuration directory. This can be relative to the
|
||||
``setup.py`` or ``setup.cfg`` file, or it can be absolute. Default is
|
||||
``''``.
|
||||
``setup.py`` or ``setup.cfg`` file, or it can be absolute. Default is to use
|
||||
`source-dir`.
|
||||
|
||||
This can also be set by passing the `-c` flag to ``setup.py``:
|
||||
|
||||
@@ -171,6 +181,14 @@ Options for setuptools integration
|
||||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
.. confval:: nitpicky
|
||||
|
||||
Run in nit-picky mode. Currently, this generates warnings for all missing
|
||||
references. See the config value :confval:`nitpick_ignore` for a way to
|
||||
exclude some references as "known missing".
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
.. confval:: pdb
|
||||
|
||||
A boolean to configure ``pdb`` on exception. Default is false.
|
||||
@@ -40,9 +40,17 @@ The WebSupport Class
|
||||
comment that was added.
|
||||
|
||||
staticdir
|
||||
If static files are served from a location besides ``'/static'``, this
|
||||
should be a string with the name of that location
|
||||
(e.g. ``'/static_files'``).
|
||||
If the static files should be created in a different location
|
||||
**and not in** ``'/static'``, this should be a string with the name of
|
||||
that location (e.g. ``builddir + '/static_files'``).
|
||||
|
||||
.. note::
|
||||
If you specify ``staticdir``, you will typically want to adjust
|
||||
``staticroot`` accordingly.
|
||||
|
||||
staticroot
|
||||
If the static files are not served from ``'/static'``, this should be a
|
||||
string with the name of that location (e.g. ``'/static_files'``).
|
||||
|
||||
docroot
|
||||
If the documentation is not served from the base path of a URL, this
|
||||
@@ -57,7 +65,7 @@ The WebSupport Class
|
||||
|
||||
|
||||
Methods
|
||||
~~~~~~~
|
||||
-------
|
||||
|
||||
.. automethod:: sphinxcontrib.websupport.WebSupport.build
|
||||
|
||||
@@ -10,7 +10,7 @@ web application. To learn more read the :ref:`websupportquickstart`.
|
||||
|
||||
.. toctree::
|
||||
|
||||
web/quickstart
|
||||
web/api
|
||||
web/searchadapters
|
||||
web/storagebackends
|
||||
quickstart
|
||||
api
|
||||
searchadapters
|
||||
storagebackends
|
||||
@@ -4,7 +4,7 @@ Web Support Quick Start
|
||||
=======================
|
||||
|
||||
Building Documentation Data
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
----------------------------
|
||||
|
||||
To make use of the web support package in your application you'll need to build
|
||||
the data it uses. This data includes pickle files representing documents,
|
||||
@@ -20,11 +20,11 @@ things are in a document. To do this you will need to create an instance of the
|
||||
|
||||
support.build()
|
||||
|
||||
This will read reStructuredText sources from `srcdir` and place the necessary
|
||||
data in `builddir`. The `builddir` will contain two sub-directories: one named
|
||||
"data" that contains all the data needed to display documents, search through
|
||||
documents, and add comments to documents. The other directory will be called
|
||||
"static" and contains static files that should be served from "/static".
|
||||
This will read reStructuredText sources from ``srcdir`` and place the necessary
|
||||
data in ``builddir``. The ``builddir`` will contain two sub-directories: one
|
||||
named "data" that contains all the data needed to display documents, search
|
||||
through documents, and add comments to documents. The other directory will be
|
||||
called "static" and contains static files that should be served from "/static".
|
||||
|
||||
.. note::
|
||||
|
||||
@@ -34,7 +34,7 @@ documents, and add comments to documents. The other directory will be called
|
||||
|
||||
|
||||
Integrating Sphinx Documents Into Your Webapp
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
----------------------------------------------
|
||||
|
||||
Now that the data is built, it's time to do something useful with it. Start off
|
||||
by creating a :class:`~.WebSupport` object for your application::
|
||||
@@ -96,7 +96,7 @@ integrate with your existing templating system. An example using `Jinja2
|
||||
|
||||
|
||||
Authentication
|
||||
--------------
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
To use certain features such as voting, it must be possible to authenticate
|
||||
users. The details of the authentication are left to your application. Once a
|
||||
@@ -146,13 +146,14 @@ add this data to the ``COMMENT_OPTIONS`` that are used in the template.
|
||||
|
||||
|
||||
Performing Searches
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
-------------------
|
||||
|
||||
To use the search form built-in to the Sphinx sidebar, create a function to
|
||||
handle requests to the url 'search' relative to the documentation root. The
|
||||
handle requests to the URL 'search' relative to the documentation root. The
|
||||
user's search query will be in the GET parameters, with the key `q`. Then use
|
||||
the :meth:`~sphinxcontrib.websupport.WebSupport.get_search_results` method to retrieve
|
||||
search results. In `Flask <http://flask.pocoo.org/>`_ that would be like this::
|
||||
the :meth:`~sphinxcontrib.websupport.WebSupport.get_search_results` method to
|
||||
retrieve search results. In `Flask <http://flask.pocoo.org/>`_ that would be
|
||||
like this::
|
||||
|
||||
@app.route('/search')
|
||||
def search():
|
||||
@@ -167,7 +168,7 @@ does.
|
||||
|
||||
|
||||
Comments & Proposals
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
--------------------
|
||||
|
||||
Now that this is done it's time to define the functions that handle the AJAX
|
||||
calls from the script. You will need three functions. The first function is
|
||||
@@ -186,9 +187,9 @@ used to add a new comment, and will call the web support method
|
||||
username=username, proposal=proposal)
|
||||
return jsonify(comment=comment)
|
||||
|
||||
You'll notice that both a `parent_id` and `node_id` are sent with the
|
||||
request. If the comment is being attached directly to a node, `parent_id`
|
||||
will be empty. If the comment is a child of another comment, then `node_id`
|
||||
You'll notice that both a ``parent_id`` and ``node_id`` are sent with the
|
||||
request. If the comment is being attached directly to a node, ``parent_id``
|
||||
will be empty. If the comment is a child of another comment, then ``node_id``
|
||||
will be empty. Then next function handles the retrieval of comments for a
|
||||
specific node, and is aptly named
|
||||
:meth:`~sphinxcontrib.websupport.WebSupport.get_data`::
|
||||
@@ -217,11 +218,11 @@ and will handle user votes on comments::
|
||||
|
||||
|
||||
Comment Moderation
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
------------------
|
||||
|
||||
By default, all comments added through :meth:`~.WebSupport.add_comment` are
|
||||
automatically displayed. If you wish to have some form of moderation, you can
|
||||
pass the `displayed` keyword argument::
|
||||
pass the ``displayed`` keyword argument::
|
||||
|
||||
comment = support.add_comment(text, node_id='node_id',
|
||||
parent_id='parent_id',
|
||||
@@ -26,13 +26,13 @@ documentation of the :class:`BaseSearch` class below.
|
||||
BaseSearch class is moved to sphinxcontrib.websupport.search from
|
||||
sphinx.websupport.search.
|
||||
|
||||
BaseSearch Methods
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
Methods
|
||||
-------
|
||||
|
||||
The following methods are defined in the BaseSearch class. Some methods do
|
||||
not need to be overridden, but some (:meth:`~BaseSearch.add_document` and
|
||||
:meth:`~BaseSearch.handle_query`) must be overridden in your subclass. For a
|
||||
working example, look at the built-in adapter for whoosh.
|
||||
The following methods are defined in the BaseSearch class. Some methods do not
|
||||
need to be overridden, but some (:meth:`~BaseSearch.add_document` and
|
||||
:meth:`~BaseSearch.handle_query`) must be overridden in your subclass. For a
|
||||
working example, look at the built-in adapter for whoosh.
|
||||
|
||||
.. automethod:: BaseSearch.init_indexing
|
||||
|
||||
@@ -27,8 +27,8 @@ documentation of the :class:`StorageBackend` class below.
|
||||
sphinx.websupport.storage.
|
||||
|
||||
|
||||
StorageBackend Methods
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
Methods
|
||||
-------
|
||||
|
||||
.. automethod:: StorageBackend.pre_build
|
||||
|
||||
@@ -1,13 +1,14 @@
|
||||
.. _builders:
|
||||
|
||||
Available builders
|
||||
==================
|
||||
========
|
||||
Builders
|
||||
========
|
||||
|
||||
.. module:: sphinx.builders
|
||||
:synopsis: Available built-in builder classes.
|
||||
|
||||
These are the built-in Sphinx builders. More builders can be added by
|
||||
:ref:`extensions <extensions>`.
|
||||
:doc:`extensions </usage/extensions/index>`.
|
||||
|
||||
The builder's "name" must be given to the **-b** command-line option of
|
||||
:program:`sphinx-build` to select a builder.
|
||||
@@ -75,8 +76,8 @@ The builder's "name" must be given to the **-b** command-line option of
|
||||
.. class:: QtHelpBuilder
|
||||
|
||||
This builder produces the same output as the standalone HTML builder, but
|
||||
also generates `Qt help`_ collection support files that allow
|
||||
the Qt collection generator to compile them.
|
||||
also generates `Qt help`_ collection support files that allow the Qt
|
||||
collection generator to compile them.
|
||||
|
||||
.. autoattribute:: name
|
||||
|
||||
@@ -144,7 +145,8 @@ The builder's "name" must be given to the **-b** command-line option of
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
Since Sphinx-1.5, the epub3 builder is used for the default builder of epub.
|
||||
Since Sphinx-1.5, the epub3 builder is used for the default builder of
|
||||
epub.
|
||||
|
||||
.. module:: sphinx.builders.latex
|
||||
.. class:: LaTeXBuilder
|
||||
@@ -155,36 +157,48 @@ The builder's "name" must be given to the **-b** command-line option of
|
||||
configuration values that customize the output of this builder, see the
|
||||
chapter :ref:`latex-options` for details.
|
||||
|
||||
The produced LaTeX file uses several LaTeX packages that may not be present
|
||||
in a "minimal" TeX distribution installation.
|
||||
|
||||
On Ubuntu xenial, the following packages need to be installed for
|
||||
successful PDF builds:
|
||||
|
||||
* ``texlive-latex-recommended``
|
||||
* ``texlive-fonts-recommended``
|
||||
* ``texlive-latex-extra``
|
||||
* ``latexmk`` (this is a Sphinx requirement on GNU/Linux and MacOS X
|
||||
for functioning of ``make latexpdf``)
|
||||
|
||||
Additional packages are needed in some circumstances (see the discussion of
|
||||
the ``'fontpkg'`` key of :confval:`latex_elements` for more information):
|
||||
|
||||
* to support occasional Cyrillic letters or words, and a fortiori if
|
||||
:confval:`language` is set to a Cyrillic language, the package
|
||||
``texlive-lang-cyrillic`` is required, and, with unmodified ``'fontpkg'``,
|
||||
also ``cm-super`` or ``cm-super-minimal``,
|
||||
* to support occasional Greek letters or words (in text, not in
|
||||
:rst:dir:`math` directive contents), ``texlive-lang-greek`` is required,
|
||||
and, with unmodified ``'fontpkg'``, also ``cm-super`` or
|
||||
``cm-super-minimal``,
|
||||
* for ``'xelatex'`` or ``'lualatex'`` (see :confval:`latex_engine`),
|
||||
``texlive-xetex`` resp. ``texlive-luatex``, and, if leaving unchanged
|
||||
``'fontpkg'``, ``fonts-freefont-otf``.
|
||||
|
||||
The testing of Sphinx LaTeX is done on Ubuntu xenial whose TeX distribution
|
||||
is based on a TeXLive 2015 snapshot dated March 2016.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
Formerly, testing had been done on Ubuntu precise (TeXLive 2009).
|
||||
|
||||
.. versionchanged:: 2.0
|
||||
Formerly, testing had been done on Ubuntu trusty (TeXLive 2013).
|
||||
|
||||
.. note::
|
||||
|
||||
The produced LaTeX file uses several LaTeX packages that may not be
|
||||
present in a "minimal" TeX distribution installation. For example, on
|
||||
Ubuntu, the following packages need to be installed for successful PDF
|
||||
builds:
|
||||
Since 1.6, ``make latexpdf`` uses ``latexmk`` (not on Windows). This
|
||||
makes sure the needed number of runs is automatically executed to get
|
||||
the cross-references, bookmarks, indices, and tables of contents right.
|
||||
|
||||
* texlive-latex-recommended
|
||||
* texlive-fonts-recommended
|
||||
* texlive-latex-extra
|
||||
* latexmk (for ``make latexpdf``)
|
||||
|
||||
Sphinx will use ``xcolor.sty`` if present: recent Ubuntu distributions
|
||||
have ``xcolor.sty`` included in latex-recommended, earlier ones have it
|
||||
in latex-xcolor. Unicode engines will need texlive-luatex or
|
||||
texlive-xetex.
|
||||
|
||||
The testing of Sphinx LaTeX is done on Ubuntu trusty with the above
|
||||
mentioned packages, which are from a TeXLive 2013 snapshot dated
|
||||
February 2014.
|
||||
|
||||
.. versionchanged:: 1.6
|
||||
Formerly, testing had been done for some years on Ubuntu precise
|
||||
(based on TeXLive 2009).
|
||||
.. versionchanged:: 1.6
|
||||
Use of ``latexmk`` for ``make latexpdf`` on GNU/Linux and Mac OS X
|
||||
|
||||
Since 1.6, ``make latexpdf`` (or
|
||||
``make -C "<builddir>/latex"`` after a ``sphinx-build`` run) uses
|
||||
``latexmk`` (not on Windows).
|
||||
One can pass to ``latexmk`` options via the ``LATEXMKOPTS``
|
||||
Makefile variable. For example:
|
||||
|
||||
@@ -192,13 +206,18 @@ The builder's "name" must be given to the **-b** command-line option of
|
||||
|
||||
make latexpdf LATEXMKOPTS="-silent"
|
||||
|
||||
reduces console output to a minimum. Also, if ``latexmk`` version is
|
||||
4.52b or higher (Jan 17) and ``xelatex`` is the :confval:`latex_engine`,
|
||||
then ``LATEXMKOPTS="-xelatex"`` will speed up PDF builds.
|
||||
reduces console output to a minimum.
|
||||
|
||||
To pass options directly to the
|
||||
``(pdf|xe|lua)latex`` executable, use variable ``LATEXOPTS`` (for example
|
||||
``LATEXOPTS="--interaction=nonstopmode"``).
|
||||
Also, if ``latexmk`` is at version 4.52b or higher (January 2017)
|
||||
``LATEXMKOPTS="-xelatex"`` speeds up PDF builds via XeLateX in case
|
||||
of numerous graphics inclusions.
|
||||
|
||||
To pass options directly to the ``(pdf|xe|lua)latex`` binary, use
|
||||
variable ``LATEXOPTS``, for example:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
make latexpdf LATEXOPTS="--halt-on-error"
|
||||
|
||||
.. autoattribute:: name
|
||||
|
||||
@@ -207,16 +226,10 @@ The builder's "name" must be given to the **-b** command-line option of
|
||||
.. autoattribute:: supported_image_types
|
||||
|
||||
Note that a direct PDF builder is being provided by `rinohtype`_. The builder's
|
||||
name is ``rinoh``. Refer to the `rinohtype manual`_ for details. There is also
|
||||
PDF builder using ReportLab in `rst2pdf`_ version 0.12 or greater. However,
|
||||
rst2pdf is no longer being actively maintained and suffers from some problems
|
||||
when used with recent Sphinx versions. See the `rst2pdf manual`_ for usage
|
||||
instructions.
|
||||
name is ``rinoh``. Refer to the `rinohtype manual`_ for details.
|
||||
|
||||
.. _rinohtype: https://github.com/brechtm/rinohtype
|
||||
.. _rinohtype manual: http://www.mos6581.org/rinohtype/quickstart.html#sphinx-builder
|
||||
.. _rst2pdf: https://github.com/rst2pdf/rst2pdf
|
||||
.. _rst2pdf manual: http://ralsina.me/static/manual.pdf
|
||||
.. _rinohtype manual: https://www.mos6581.org/rinohtype/quickstart.html#sphinx-builder
|
||||
|
||||
.. module:: sphinx.builders.text
|
||||
.. class:: TextBuilder
|
||||
@@ -291,7 +304,7 @@ instructions.
|
||||
globalcontext_filename = 'globalcontext.phpdump'
|
||||
searchindex_filename = 'searchindex.phpdump'
|
||||
|
||||
.. _PHP serialization: https://pypi.python.org/pypi/phpserialize
|
||||
.. _PHP serialization: https://pypi.org/project/phpserialize/
|
||||
|
||||
.. attribute:: implementation
|
||||
|
||||
@@ -314,7 +327,6 @@ instructions.
|
||||
|
||||
The filename for the search index Sphinx generates.
|
||||
|
||||
|
||||
See :ref:`serialization-details` for details about the output format.
|
||||
|
||||
.. versionadded:: 0.5
|
||||
@@ -403,8 +415,8 @@ instructions.
|
||||
.. class:: CheckExternalLinksBuilder
|
||||
|
||||
This builder scans all documents for external links, tries to open them with
|
||||
:mod:`urllib2`, and writes an overview which ones are broken and redirected
|
||||
to standard output and to :file:`output.txt` in the output directory.
|
||||
``requests``, and writes an overview which ones are broken and redirected to
|
||||
standard output and to :file:`output.txt` in the output directory.
|
||||
|
||||
.. autoattribute:: name
|
||||
|
||||
@@ -412,6 +424,10 @@ instructions.
|
||||
|
||||
.. autoattribute:: supported_image_types
|
||||
|
||||
.. versionchanged:: 1.5
|
||||
|
||||
Since Sphinx-1.5, the linkcheck builder comes to use requests module.
|
||||
|
||||
.. module:: sphinx.builders.xml
|
||||
.. class:: XMLBuilder
|
||||
|
||||
File diff suppressed because it is too large.
Load diff
@@ -41,10 +41,14 @@ you can also enable the :mod:`napoleon <sphinx.ext.napoleon>` extension.
|
||||
docstrings to correct reStructuredText before :mod:`autodoc` processes them.
|
||||
|
||||
.. _Google:
|
||||
https://google.github.io/styleguide/pyguide.html#Comments
|
||||
https://github.com/google/styleguide/blob/gh-pages/pyguide.md#38-comments-and-docstrings
|
||||
.. _NumPy:
|
||||
https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt
|
||||
|
||||
|
||||
Directives
|
||||
----------
|
||||
|
||||
:mod:`autodoc` provides several directives that are versions of the usual
|
||||
:rst:dir:`py:module`, :rst:dir:`py:class` and so forth. On parsing time, they
|
||||
import the corresponding module and extract the docstring of the given objects,
|
||||
@@ -103,8 +107,10 @@ inserting them into the page source under a suitable :rst:dir:`py:module`,
|
||||
will document all non-private member functions and properties (that is,
|
||||
those whose name doesn't start with ``_``).
|
||||
|
||||
For modules, ``__all__`` will be respected when looking for members; the
|
||||
order of the members will also be the order in ``__all__``.
|
||||
For modules, ``__all__`` will be respected when looking for members unless
|
||||
you give the ``ignore-module-all`` flag option. Without
|
||||
``ignore-module-all``, the order of the members will also be the order in
|
||||
``__all__``.
|
||||
|
||||
You can also give an explicit list of members; only these will then be
|
||||
documented::
|
||||
@@ -112,8 +118,17 @@ inserting them into the page source under a suitable :rst:dir:`py:module`,
|
||||
.. autoclass:: Noodle
|
||||
:members: eat, slurp
|
||||
|
||||
* If you want to make the ``members`` option (or other flag options described
|
||||
below) the default, see :confval:`autodoc_default_flags`.
|
||||
* If you want to make the ``members`` option (or other options described
|
||||
below) the default, see :confval:`autodoc_default_options`.
|
||||
|
||||
.. tip::
|
||||
|
||||
You can use a negated form, :samp:`'no-{flag}'`, as an option of
|
||||
autodoc directive, to disable it temporarily. For example::
|
||||
|
||||
.. automodule:: foo
|
||||
:no-undoc-members:
|
||||
|
||||
|
||||
* Members without docstrings will be left out, unless you give the
|
||||
``undoc-members`` flag option::
|
||||
@@ -295,6 +310,9 @@ inserting them into the page source under a suitable :rst:dir:`py:module`,
|
||||
well-behaved decorating functions.
|
||||
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
There are also new config values that you can set:
|
||||
|
||||
.. confval:: autoclass_content
|
||||
@@ -339,20 +357,39 @@ There are also new config values that you can set:
|
||||
This value is a list of autodoc directive flags that should be automatically
|
||||
applied to all autodoc directives. The supported flags are ``'members'``,
|
||||
``'undoc-members'``, ``'private-members'``, ``'special-members'``,
|
||||
``'inherited-members'`` and ``'show-inheritance'``.
|
||||
|
||||
If you set one of these flags in this config value, you can use a negated
|
||||
form, :samp:`'no-{flag}'`, in an autodoc directive, to disable it once.
|
||||
For example, if ``autodoc_default_flags`` is set to ``['members',
|
||||
'undoc-members']``, and you write a directive like this::
|
||||
|
||||
.. automodule:: foo
|
||||
:no-undoc-members:
|
||||
|
||||
the directive will be interpreted as if only ``:members:`` was given.
|
||||
``'inherited-members'``, ``'show-inheritance'``, ``'ignore-module-all'``
|
||||
and ``'exclude-members'``.
|
||||
|
||||
.. versionadded:: 1.0
|
||||
|
||||
.. deprecated:: 1.8
|
||||
|
||||
Integrated into :confval:`autodoc_default_options`.
|
||||
|
||||
.. confval:: autodoc_default_options
|
||||
|
||||
The default options for autodoc directives. They are applied to all autodoc
|
||||
directives automatically. It must be a dictionary which maps option names
|
||||
to the values. For example::
|
||||
|
||||
autodoc_default_options = {
|
||||
'members': 'var1, var2',
|
||||
'member-order': 'bysource',
|
||||
'special-members': '__init__',
|
||||
'undoc-members': None,
|
||||
'exclude-members': '__weakref__'
|
||||
}
|
||||
|
||||
Setting ``None`` is equivalent to giving the option name in the list format
|
||||
(i.e. it means "yes/true/on").
|
||||
|
||||
The supported options are ``'members'``, ``'member-order'``,
|
||||
``'undoc-members'``, ``'private-members'``, ``'special-members'``,
|
||||
``'inherited-members'``, ``'show-inheritance'``, ``'ignore-module-all'`` and
|
||||
``'exclude-members'``.
|
||||
|
||||
.. versionadded:: 1.8
|
||||
|
||||
.. confval:: autodoc_docstring_signature
|
||||
|
||||
Functions imported from C modules cannot be introspected, and therefore the
|
||||
@@ -372,7 +409,7 @@ There are also new config values that you can set:
|
||||
This value contains a list of modules to be mocked up. This is useful when
|
||||
some external dependencies are not met at build time and break the building
|
||||
process. You may only specify the root package of the dependencies
|
||||
themselves and ommit the sub-modules:
|
||||
themselves and omit the sub-modules:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
@@ -386,6 +423,34 @@ There are also new config values that you can set:
|
||||
This config value only requires to declare the top-level modules that
|
||||
should be mocked.
|
||||
|
||||
.. confval:: autodoc_warningiserror
|
||||
|
||||
This value controls the behavior of :option:`sphinx-build -W` during
|
||||
importing modules.
|
||||
If ``False`` is given, autodoc forcely suppresses the error if the imported
|
||||
module emits warnings. By default, ``True``.
|
||||
|
||||
.. confval:: autodoc_inherit_docstrings
|
||||
|
||||
This value controls the docstrings inheritance.
|
||||
If set to True the docstring for classes or methods, if not explicitly set,
|
||||
is inherited form parents.
|
||||
|
||||
The default is ``True``.
|
||||
|
||||
.. versionadded:: 1.7
|
||||
|
||||
.. confval:: suppress_warnings
|
||||
:noindex:
|
||||
|
||||
:mod:`autodoc` supports to suppress warning messages via
|
||||
:confval:`suppress_warnings`. It allows following warnings types in
|
||||
addition:
|
||||
|
||||
* autodoc
|
||||
* autodoc.import_object
|
||||
|
||||
|
||||
Docstring preprocessing
|
||||
-----------------------
|
||||
|
||||
@@ -27,6 +27,7 @@ default. The ``autosectionlabel_prefix_document`` configuration variable can be
|
||||
used to make headings which appear multiple times but in different documents
|
||||
unique.
|
||||
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
@@ -25,7 +25,6 @@ The :mod:`sphinx.ext.autosummary` extension does this in two parts:
|
||||
These files by default contain only the corresponding
|
||||
:mod:`sphinx.ext.autodoc` directive, but can be customized with templates.
|
||||
|
||||
|
||||
.. rst:directive:: autosummary
|
||||
|
||||
Insert a table that contains links to documented items, and a short summary
|
||||
@@ -59,7 +58,6 @@ The :mod:`sphinx.ext.autosummary` extension does this in two parts:
|
||||
:event:`autodoc-process-docstring` and :event:`autodoc-process-signature`
|
||||
hooks as :mod:`~sphinx.ext.autodoc`.
|
||||
|
||||
|
||||
**Options**
|
||||
|
||||
* If you want the :rst:dir:`autosummary` table to also serve as a
|
||||
@@ -125,6 +123,9 @@ text of the form::
|
||||
If the ``-o`` option is not given, the script will place the output files in the
|
||||
directories specified in the ``:toctree:`` options.
|
||||
|
||||
For more information, refer to the :doc:`sphinx-autogen documentation
|
||||
</man/sphinx-autogen>`
|
||||
|
||||
|
||||
Generating stub pages automatically
|
||||
-----------------------------------
|
||||
@@ -202,6 +203,13 @@ The following variables available in the templates:
|
||||
List containing names of all members of the module or class. Only available
|
||||
for modules and classes.
|
||||
|
||||
.. data:: inherited_members
|
||||
|
||||
List containing names of all inherited members of class. Only available for
|
||||
classes.
|
||||
|
||||
.. versionadded:: 1.8.0
|
||||
|
||||
.. data:: functions
|
||||
|
||||
List containing names of "public" functions in the module. Here, "public"
|
||||
@@ -234,7 +242,7 @@ Additionally, the following filters are available
|
||||
.. function:: escape(s)
|
||||
|
||||
Escape any special characters in the text to be used in formatting RST
|
||||
contexts. For instance, this prevents asterisks making things bolt. This
|
||||
contexts. For instance, this prevents asterisks making things bold. This
|
||||
replaces the builtin Jinja `escape filter`_ that does html-escaping.
|
||||
|
||||
.. function:: underline(s, line='=')
|
||||
@@ -4,7 +4,6 @@
|
||||
.. module:: sphinx.ext.coverage
|
||||
:synopsis: Check Python modules and C API for coverage in the documentation.
|
||||
|
||||
|
||||
This extension features one additional builder, the :class:`CoverageBuilder`.
|
||||
|
||||
.. class:: CoverageBuilder
|
||||
@@ -14,7 +13,6 @@ This extension features one additional builder, the :class:`CoverageBuilder`.
|
||||
|
||||
.. todo:: Write this section.
|
||||
|
||||
|
||||
Several new configuration values can be used to specify what the builder
|
||||
should check:
|
||||
|
||||
@@ -80,12 +80,24 @@ a comma-separated list of group names.
|
||||
.. doctest::
|
||||
:pyversion: > 3.3
|
||||
|
||||
The supported operands are ``<``, ``<=``, ``==``, ``>=``, ``>``, and
|
||||
comparison is performed by `distutils.version.LooseVersion
|
||||
<https://www.python.org/dev/peps/pep-0386/#distutils>`__.
|
||||
The following operands are supported:
|
||||
|
||||
* ``~=``: Compatible release clause
|
||||
* ``==``: Version matching clause
|
||||
* ``!=``: Version exclusion clause
|
||||
* ``<=``, ``>=``: Inclusive ordered comparison clause
|
||||
* ``<``, ``>``: Exclusive ordered comparison clause
|
||||
* ``===``: Arbitrary equality clause.
|
||||
|
||||
``pyversion`` option is followed `PEP-440: Version Specifiers
|
||||
<https://www.python.org/dev/peps/pep-0440/#version-specifiers>`__.
|
||||
|
||||
.. versionadded:: 1.6
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
Supported PEP-440 operands and notations
|
||||
|
||||
Note that like with standard doctests, you have to use ``<BLANKLINE>`` to
|
||||
signal a blank line in the expected output. The ``<BLANKLINE>`` is removed
|
||||
when building presentation output (HTML, LaTeX etc.).
|
||||
@@ -153,7 +165,6 @@ a comma-separated list of group names.
|
||||
|
||||
Output text.
|
||||
|
||||
|
||||
The following is an example for the usage of the directives. The test via
|
||||
:rst:dir:`doctest` and the test via :rst:dir:`testcode` and
|
||||
:rst:dir:`testoutput` are equivalent. ::
|
||||
@@ -187,6 +198,81 @@ The following is an example for the usage of the directives. The test via
|
||||
This parrot wouldn't voom if you put 3000 volts through it!
|
||||
|
||||
|
||||
Skipping tests conditionally
|
||||
----------------------------
|
||||
|
||||
``skipif``, a string option, can be used to skip directives conditionally. This
|
||||
may be useful e.g. when a different set of tests should be run depending on the
|
||||
environment (hardware, network/VPN, optional dependencies or different versions
|
||||
of dependencies). The ``skipif`` option is supported by all of the doctest
|
||||
directives. Below are typical use cases for ``skipif`` when used for different
|
||||
directives:
|
||||
|
||||
- :rst:dir:`testsetup` and :rst:dir:`testcleanup`
|
||||
|
||||
- conditionally skip test setup and/or cleanup
|
||||
- customize setup/cleanup code per environment
|
||||
|
||||
- :rst:dir:`doctest`
|
||||
|
||||
- conditionally skip both a test and its output verification
|
||||
|
||||
- :rst:dir:`testcode`
|
||||
|
||||
- conditionally skip a test
|
||||
- customize test code per environment
|
||||
|
||||
- :rst:dir:`testoutput`
|
||||
|
||||
- conditionally skip output assertion for a skipped test
|
||||
- expect different output depending on the environment
|
||||
|
||||
The value of the ``skipif`` option is evaluated as a Python expression. If the
|
||||
result is a true value, the directive is omitted from the test run just as if
|
||||
it wasn't present in the file at all.
|
||||
|
||||
Instead of repeating an expression, the :confval:`doctest_global_setup`
|
||||
configuration option can be used to assign it to a variable which can then be
|
||||
used instead.
|
||||
|
||||
Here's an example which skips some tests if Pandas is not installed:
|
||||
|
||||
.. code-block:: py
|
||||
:caption: conf.py
|
||||
|
||||
extensions = ['sphinx.ext.doctest']
|
||||
doctest_global_setup = '''
|
||||
try:
|
||||
import pandas as pd
|
||||
except ImportError:
|
||||
pd = None
|
||||
'''
|
||||
|
||||
.. code-block:: rst
|
||||
:caption: contents.rst
|
||||
|
||||
.. testsetup::
|
||||
:skipif: pd is None
|
||||
|
||||
data = pd.Series([42])
|
||||
|
||||
.. doctest::
|
||||
:skipif: pd is None
|
||||
|
||||
>>> data.iloc[0]
|
||||
42
|
||||
|
||||
.. testcode::
|
||||
:skipif: pd is None
|
||||
|
||||
print(data.iloc[-1])
|
||||
|
||||
.. testoutput::
|
||||
:skipif: pd is None
|
||||
|
||||
42
|
||||
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
@@ -29,7 +29,7 @@ Todo:
|
||||
* You have to also use ``sphinx.ext.todo`` extension
|
||||
|
||||
.. _Google Python Style Guide:
|
||||
http://google.github.io/styleguide/pyguide.html
|
||||
https://google.github.io/styleguide/pyguide.html
|
||||
|
||||
"""
|
||||
|
||||
@@ -178,7 +178,7 @@ class ExampleError(Exception):
|
||||
self.code = code
|
||||
|
||||
|
||||
class ExampleClass(object):
|
||||
class ExampleClass:
|
||||
"""The summary line for a class docstring should fit on one line.
|
||||
|
||||
If the class has public attributes, they may be documented here
|
||||
File renamed without changes.
@@ -223,7 +223,7 @@ class ExampleError(Exception):
|
||||
self.code = code
|
||||
|
||||
|
||||
class ExampleClass(object):
|
||||
class ExampleClass:
|
||||
"""The summary line for a class docstring should fit on one line.
|
||||
|
||||
If the class has public attributes, they may be documented here
|
||||
File renamed without changes.
Loaded 100 of 914 files, more files were not shown because too many files have changed in this diff.
Show more
Reference in new issue
Block a user