Merge branch 'master' into docs/extension-tutorials
@ -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
|
||||
|
8
.codecov.yml
Normal file
@ -0,0 +1,8 @@
|
||||
coverage:
|
||||
status:
|
||||
project:
|
||||
default:
|
||||
enabled: no
|
||||
patch:
|
||||
default:
|
||||
enabled: no
|
8
.github/ISSUE_TEMPLATE.md
vendored
@ -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>
|
||||
|
||||
|
11
.gitignore
vendored
@ -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/
|
||||
|
81
.travis.yml
@ -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
|
||||
|
16
AUTHORS
@ -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!
|
||||
|
||||
|
133
CONTRIBUTING.rst
@ -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.
|
||||
|
569
EXAMPLES
@ -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.
|
||||
|
90
LICENSE
@ -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:
|
||||
|
||||
|
@ -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
|
||||
|
82
Makefile
@ -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)
|
||||
|
140
README.rst
@ -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
|
||||
|
||||
|
@ -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
|
||||
|
0
doc/more.png → doc/_static/more.png
vendored
Before Width: | Height: | Size: 1.3 KiB After Width: | Height: | Size: 1.3 KiB |
Before Width: | Height: | Size: 25 KiB After Width: | Height: | Size: 25 KiB |
Before Width: | Height: | Size: 32 KiB After Width: | Height: | Size: 32 KiB |
Before Width: | Height: | Size: 26 KiB After Width: | Height: | Size: 26 KiB |
Before Width: | Height: | Size: 39 KiB After Width: | Height: | Size: 39 KiB |
Before Width: | Height: | Size: 56 KiB After Width: | Height: | Size: 56 KiB |
Before Width: | Height: | Size: 39 KiB After Width: | Height: | Size: 39 KiB |
Before Width: | Height: | Size: 73 KiB After Width: | Height: | Size: 73 KiB |
Before Width: | Height: | Size: 71 KiB After Width: | Height: | Size: 71 KiB |
Before Width: | Height: | Size: 82 KiB After Width: | Height: | Size: 82 KiB |
Before Width: | Height: | Size: 32 KiB After Width: | Height: | Size: 32 KiB |
Before Width: | Height: | Size: 100 KiB After Width: | Height: | Size: 100 KiB |
Before Width: | Height: | Size: 86 KiB After Width: | Height: | Size: 86 KiB |
Before Width: | Height: | Size: 38 KiB After Width: | Height: | Size: 38 KiB |
Before Width: | Height: | Size: 82 KiB After Width: | Height: | Size: 82 KiB |
Before Width: | Height: | Size: 90 KiB After Width: | Height: | Size: 90 KiB |
Before Width: | Height: | Size: 42 KiB After Width: | Height: | Size: 42 KiB |
Before Width: | Height: | Size: 28 KiB After Width: | Height: | Size: 28 KiB |
Before Width: | Height: | Size: 38 KiB After Width: | Height: | Size: 38 KiB |
Before Width: | Height: | Size: 27 KiB After Width: | Height: | Size: 27 KiB |
Before Width: | Height: | Size: 28 KiB After Width: | Height: | Size: 28 KiB |
Before Width: | Height: | Size: 30 KiB After Width: | Height: | Size: 30 KiB |
Before Width: | Height: | Size: 32 KiB After Width: | Height: | Size: 32 KiB |
Before Width: | Height: | Size: 14 KiB After Width: | Height: | Size: 14 KiB |
13
doc/_templates/index.html
vendored
@ -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>
|
||||
|
30
doc/_templates/indexsidebar.html
vendored
@ -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>
|
||||
|
11
doc/_themes/sphinx13/layout.html
vendored
@ -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>
|
||||
|
40
doc/_themes/sphinx13/static/sphinx13.css
vendored
@ -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 {
|
||||
|
33
doc/conf.py
@ -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)
|
||||
|
@ -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
|
||||
==================
|
||||
|
||||
|
@ -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.
|
@ -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
|
||||
|
17
doc/extdev/i18n.rst
Normal file
@ -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.
|
||||
|
@ -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()
|
||||
|
@ -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
|
||||
|
9
doc/extdev/projectapi.rst
Normal file
@ -0,0 +1,9 @@
|
||||
.. _project-api:
|
||||
|
||||
Project API
|
||||
===========
|
||||
|
||||
.. currentmodule:: sphinx.project
|
||||
|
||||
.. autoclass:: Project
|
||||
:members:
|
22
doc/extdev/utils.rst
Normal file
@ -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
|
21
doc/faq.rst
@ -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:
|
||||
|
@ -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
doc/install.rst
@ -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.
|
Before Width: | Height: | Size: 25 KiB |
@ -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`).
|
133
doc/latex.rst
@ -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::
|
||||
|
||||
|
@ -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
|
||||
|
22
doc/man/index.rst
Normal file
@ -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
|
@ -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
|
||||
|
93
doc/man/sphinx-autogen.rst
Normal file
@ -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)`
|
@ -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.
|
||||
|
@ -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.
|
Before Width: | Height: | Size: 146 KiB |
@ -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
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
300
doc/theming.rst
@ -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
|
||||
|
@ -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
|
@ -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
|