Merge "doc: Minor rework of usage doc"
This commit is contained in:
Zuul
Gerrit Code Review
commit
f4a1a7dec0
|
|
@ -8,7 +8,7 @@ sys.path.insert(0, os.path.abspath('../..'))
|
|||
|
||||
# Add any Sphinx extension module names here, as strings. They can be
|
||||
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
|
||||
extensions = ['sphinx.ext.autodoc']
|
||||
extensions = ['sphinx.ext.autodoc', 'sphinx.ext.todo']
|
||||
# make openstackdocstheme optional to not increase the needed dependencies
|
||||
try:
|
||||
import openstackdocstheme
|
||||
|
|
|
|||
|
|
@ -2,18 +2,19 @@
|
|||
Usage
|
||||
=======
|
||||
|
||||
`pbr` is a setuptools plugin and so to use it you must use setuptools and call
|
||||
``setuptools.setup()``. While the normal setuptools facilities are available,
|
||||
pbr makes it possible to express them through static data files.
|
||||
*pbr* is a *setuptools* plugin and so to use it you must use *setuptools* and
|
||||
call ``setuptools.setup()``. While the normal *setuptools* facilities are
|
||||
available, *pbr* makes it possible to express them through static data files.
|
||||
|
||||
.. _setup_py:
|
||||
|
||||
setup.py
|
||||
--------
|
||||
``setup.py``
|
||||
------------
|
||||
|
||||
`pbr` only requires a minimal `setup.py` file compared to a standard setuptools
|
||||
project. This is because most configuration is located in static configuration
|
||||
files. This recommended minimal `setup.py` file should look something like this::
|
||||
*pbr* only requires a minimal ``setup.py`` file compared to a standard
|
||||
*setuptools* project. This is because most configuration is located in static
|
||||
configuration files. This recommended minimal ``setup.py`` file should look
|
||||
something like this::
|
||||
|
||||
#!/usr/bin/env python
|
||||
|
||||
|
|
@ -26,22 +27,22 @@ files. This recommended minimal `setup.py` file should look something like this:
|
|||
|
||||
.. note::
|
||||
|
||||
It is necessary to specify ``pbr=True`` to enabled `pbr` functionality.
|
||||
It is necessary to specify ``pbr=True`` to enabled *pbr* functionality.
|
||||
|
||||
.. note::
|
||||
|
||||
While one can pass any arguments supported by setuptools to `setup()`,
|
||||
any conflicting arguments supplied in `setup.cfg` will take precedence.
|
||||
While one can pass any arguments supported by setuptools to ``setup()``,
|
||||
any conflicting arguments supplied in ``setup.cfg`` will take precedence.
|
||||
|
||||
setup.cfg
|
||||
---------
|
||||
.. _setup_cfg:
|
||||
|
||||
The `setup.cfg` file is an ini-like file that can mostly replace the `setup.py`
|
||||
file. It is based on the distutils2_ `setup.cfg` file. A simple sample can be
|
||||
found in `pbr`'s own `setup.cfg` (it uses its own machinery to install
|
||||
itself):
|
||||
``setup.cfg``
|
||||
-------------
|
||||
|
||||
.. _distutils2: http://alexis.notmyidea.org/distutils2/setupcfg.html
|
||||
The ``setup.cfg`` file is an INI-like file that can mostly replace the
|
||||
``setup.py`` file. It is similar to the ``setup.cfg`` file found in recent
|
||||
versions of `setuptools`__. A simple sample can be found in *pbr*'s own
|
||||
``setup.cfg`` (it uses its own machinery to install itself):
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -86,23 +87,29 @@ itself):
|
|||
pbr.config.drivers =
|
||||
plain = pbr.cfg.driver:Plain
|
||||
|
||||
`pbr` provides its own section in these documents, ostensibly called ``pbr``,
|
||||
and provides a custom version of Sphinx's ``build_sphinx`` section. Most other
|
||||
sections are provided by setuptools and may influence either the build itself
|
||||
or the output of various `setuptools commands`_. The remaining sections are
|
||||
provided by libraries that provide setuptools extensions, such as
|
||||
``extract_mesages`` (provided by Babel_). Some of these are described below.
|
||||
Recent versions of `setuptools`_ provide many of the same sections as *pbr*.
|
||||
However, *pbr* does provide a number of additional sections:
|
||||
|
||||
.. _setuptools commands: https://setuptools.readthedocs.io/en/latest/setuptools.html#command-reference
|
||||
.. _Babel: http://babel.pocoo.org/en/latest/setup.html
|
||||
.. _setuptools: http://www.sphinx-doc.org/en/stable/setuptools.html
|
||||
- ``files``
|
||||
- ``entry_points``
|
||||
- ``backwards_compat``
|
||||
- ``pbr``
|
||||
|
||||
In addition, there are some modifications to other sections:
|
||||
|
||||
- ``metadata``
|
||||
- ``build_sphinx``
|
||||
|
||||
For all other sections, you should refer to either the `setuptools`_
|
||||
documentation or the documentation of the package that provides the section,
|
||||
such as the ``extract_mesages`` section provided by Babel__.
|
||||
|
||||
.. note::
|
||||
|
||||
Comments may be used in `setup.cfg`, however all comments should start with
|
||||
a `#` and may be on a single line, or in line, with at least one white space
|
||||
character immediately preceding the `#`. Semicolons are not a supported
|
||||
comment delimiter. For instance::
|
||||
Comments may be used in ``setup.cfg``, however all comments should start
|
||||
with a ``#`` and may be on a single line, or in line, with at least one
|
||||
white space character immediately preceding the ``#``. Semicolons are not a
|
||||
supported comment delimiter. For instance::
|
||||
|
||||
[section]
|
||||
# A comment at the start of a dedicated line
|
||||
|
|
@ -112,105 +119,135 @@ provided by libraries that provide setuptools extensions, such as
|
|||
# A comment on a dedicated line
|
||||
value3
|
||||
|
||||
files
|
||||
~~~~~
|
||||
__ http://setuptools.readthedocs.io/en/latest/setuptools.html#configuring-setup-using-setup-cfg-files
|
||||
__ http://babel.pocoo.org/en/latest/setup.html
|
||||
|
||||
``files``
|
||||
~~~~~~~~~
|
||||
|
||||
The ``files`` section defines the install location of files in the package
|
||||
using three fundamental keys: ``packages``, ``namespace_packages``, and
|
||||
``data_files``.
|
||||
|
||||
``packages``
|
||||
|
||||
A list of top-level packages that should be installed. The behavior of
|
||||
packages is similar to ``setuptools.find_packages`` in that it recurses the
|
||||
python package hierarchy below the given top level and installs all of it. If
|
||||
Python package hierarchy below the given top level and installs all of it. If
|
||||
``packages`` is not specified, it defaults to the value of the ``name`` field
|
||||
given in the ``[metadata]`` section.
|
||||
|
||||
``namespace_packages``
|
||||
|
||||
Similar to ``packages``, but is a list of packages that provide namespace
|
||||
packages.
|
||||
|
||||
``data_files``
|
||||
|
||||
A list of files to be installed. The format is an indented block that
|
||||
contains key value pairs which specify target directory and source file to
|
||||
install there. More than one source file for a directory may be indicated
|
||||
with a further indented list. Source files are stripped of leading
|
||||
directories. Additionally, `pbr` supports a simple file globbing syntax for
|
||||
installing entire directory structures, thus::
|
||||
directories. Additionally, *pbr* supports a simple file globbing syntax for
|
||||
installing entire directory structures. For example::
|
||||
|
||||
[files]
|
||||
data_files =
|
||||
etc/pbr = etc/pbr/*
|
||||
etc/neutron =
|
||||
etc/api-paste.ini
|
||||
etc/dhcp-agent.ini
|
||||
etc/init.d = neutron.init
|
||||
[files]
|
||||
data_files =
|
||||
etc/pbr = etc/pbr/*
|
||||
etc/neutron =
|
||||
etc/api-paste.ini
|
||||
etc/dhcp-agent.ini
|
||||
etc/init.d = neutron.init
|
||||
|
||||
will result in `/etc/neutron` containing `api-paste.ini` and `dhcp-agent.ini`,
|
||||
both of which pbr will expect to find in the `etc` directory in the root of
|
||||
the source tree. Additionally, `neutron.init` from that dir will be installed
|
||||
in `/etc/init.d`. All of the files and directories located under `etc/pbr` in
|
||||
the source tree will be installed into `/etc/pbr`.
|
||||
This will result in ``/etc/neutron`` containing ``api-paste.ini`` and
|
||||
``dhcp-agent.ini``, both of which *pbr* will expect to find in the ``etc``
|
||||
directory in the root of the source tree. Additionally, ``neutron.init`` from
|
||||
that directory will be installed in ``/etc/init.d``. All of the files and
|
||||
directories located under ``etc/pbr`` in the source tree will be installed
|
||||
into ``/etc/pbr``.
|
||||
|
||||
Note that this behavior is relative to the effective root of the environment
|
||||
into which the packages are installed, so depending on available permissions
|
||||
this could be the actual system-wide `/etc` directory or just a top-level
|
||||
`etc` subdirectory of a virtualenv.
|
||||
this could be the actual system-wide ``/etc`` directory or just a top-level
|
||||
``etc`` subdirectory of a *virtualenv*.
|
||||
|
||||
``entry_points``
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
The ``entry_points`` section defines entry points for generated console scripts
|
||||
and Python libraries. This is actually provided by *setuptools* but is
|
||||
documented here owing to its importance.
|
||||
|
||||
The general syntax of specifying entry points is a top level name indicating
|
||||
the entry point group name, followed by one or more key value pairs naming
|
||||
the entry point to be installed. For instance::
|
||||
|
||||
[entry_points]
|
||||
console_scripts =
|
||||
pbr = pbr.cmd:main
|
||||
pbr.config.drivers =
|
||||
plain = pbr.cfg.driver:Plain
|
||||
fancy = pbr.cfg.driver:Fancy
|
||||
|
||||
Will cause a console script called *pbr* to be installed that executes the
|
||||
``main`` function found in ``pbr.cmd``. Additionally, two entry points will be
|
||||
installed for ``pbr.config.drivers``, one called ``plain`` which maps to the
|
||||
``Plain`` class in ``pbr.cfg.driver`` and one called ``fancy`` which maps to
|
||||
the ``Fancy`` class in ``pbr.cfg.driver``.
|
||||
|
||||
``backwards_compat``
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. todo:: Describe this section
|
||||
|
||||
.. _pbr-setup-cfg:
|
||||
|
||||
pbr
|
||||
~~~
|
||||
``pbr``
|
||||
~~~~~~~
|
||||
|
||||
The ``pbr`` section controls `pbr` specific options and behaviours.
|
||||
The ``pbr`` section controls *pbr*-specific options and behaviours.
|
||||
|
||||
``autodoc_tree_index_modules``
|
||||
|
||||
A boolean option controlling whether `pbr` should generate an index of
|
||||
modules using `sphinx-apidoc`. By default, all files except `setup.py` are
|
||||
included, but this can be overridden using the ``autodoc_tree_excludes``
|
||||
A boolean option controlling whether *pbr* should generate an index of
|
||||
modules using ``sphinx-apidoc``. By default, all files except ``setup.py``
|
||||
are included, but this can be overridden using the ``autodoc_tree_excludes``
|
||||
option.
|
||||
|
||||
``autodoc_tree_excludes``
|
||||
|
||||
A list of modules to exclude when building documentation using
|
||||
`sphinx-apidoc`. Defaults to ``[setup.py]``. Refer to the
|
||||
`sphinx-apidoc man page`_ for more information.
|
||||
``sphinx-apidoc``. Defaults to ``[setup.py]``. Refer to the
|
||||
`sphinx-apidoc man page`__ for more information.
|
||||
|
||||
.. _sphinx-apidoc man page: http://sphinx-doc.org/man/sphinx-apidoc.html
|
||||
__ http://sphinx-doc.org/man/sphinx-apidoc.html
|
||||
|
||||
``autodoc_index_modules``
|
||||
|
||||
A boolean option controlling whether `pbr` should itself generates
|
||||
A boolean option controlling whether *pbr* should itself generates
|
||||
documentation for Python modules of the project. By default, all found Python
|
||||
modules are included; some of them can be excluded by listing them in
|
||||
``autodoc_exclude_modules``.
|
||||
|
||||
``autodoc_exclude_modules``
|
||||
|
||||
A list of modules to exclude when building module documentation using `pbr`.
|
||||
`fnmatch` style pattern (e.g. `myapp.tests.*`) can be used.
|
||||
A list of modules to exclude when building module documentation using *pbr*.
|
||||
*fnmatch* style pattern (e.g. ``myapp.tests.*``) can be used.
|
||||
|
||||
``api_doc_dir``
|
||||
|
||||
A subdirectory inside the ``build_sphinx.source_dir`` where
|
||||
auto-generated API documentation should be written, if
|
||||
``autodoc_index_modules`` is set to True. Defaults to ``"api"``.
|
||||
A subdirectory inside the ``build_sphinx.source_dir`` where auto-generated
|
||||
API documentation should be written, if ``autodoc_index_modules`` is set to
|
||||
True. Defaults to ``"api"``.
|
||||
|
||||
.. note::
|
||||
|
||||
When using ``autodoc_tree_excludes`` or ``autodoc_index_modules`` you may
|
||||
also need to set ``exclude_patterns`` in your Sphinx configuration file
|
||||
(generally found at `doc/source/conf.py` in most OpenStack projects)
|
||||
(generally found at ``doc/source/conf.py`` in most OpenStack projects)
|
||||
otherwise Sphinx may complain about documents that are not in a toctree.
|
||||
This is especially true if the ``[sphinx_build] warning-is-error`` option is
|
||||
set. See the `Sphinx build configuration file`_ documentation for more
|
||||
set. See the `Sphinx build configuration file`__ documentation for more
|
||||
information on configuring Sphinx.
|
||||
|
||||
.. _Sphinx build configuration file: http://sphinx-doc.org/config.html
|
||||
__ http://sphinx-doc.org/config.html
|
||||
|
||||
.. versionchanged:: 2.0
|
||||
|
||||
|
|
@ -219,17 +256,30 @@ The ``pbr`` section controls `pbr` specific options and behaviours.
|
|||
feature was broken in 1.10 and was removed in pbr 2.0 in favour of the
|
||||
``[build_sphinx] warning-is-error`` provided in Sphinx 1.5+.
|
||||
|
||||
build_sphinx
|
||||
``metadata``
|
||||
~~~~~~~~~~~~
|
||||
|
||||
The ``build_sphinx`` section is a version of the ``build_sphinx`` setuptools
|
||||
.. todo:: Describe this section
|
||||
|
||||
.. _build_sphinx-setup-cfg:
|
||||
|
||||
``build_sphinx``
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
.. versionchanged:: 3.0
|
||||
|
||||
The ``build_sphinx`` plugin used to default to building both HTML and man
|
||||
page output. This is no longer the case, and you should explicitly set
|
||||
``builders`` to ``html man`` if you wish to retain this behavior.
|
||||
|
||||
The ``build_sphinx`` section is a version of the ``build_sphinx`` *setuptools*
|
||||
plugin provided with Sphinx. This plugin extends the original plugin to add the
|
||||
following:
|
||||
|
||||
- Automatic generation of module documentation using the apidoc tool
|
||||
- Automatic generation of module documentation using the ``sphinx-apidoc`` tool
|
||||
|
||||
- Automatic configuration of the `project`, `version` and `release` settings
|
||||
using information from `pbr` itself
|
||||
- Automatic configuration of the ``project``, ``version`` and ``release``
|
||||
settings using information from *pbr* itself
|
||||
|
||||
- Support for multiple builders using the ``builders`` configuration option
|
||||
|
||||
|
|
@ -237,14 +287,13 @@ following:
|
|||
|
||||
Only applies to Sphinx < 1.6. See documentation on ``builders`` below.
|
||||
|
||||
The version of ``build_sphinx`` provided by `pbr` provides a single additional
|
||||
The version of ``build_sphinx`` provided by *pbr* provides a single additional
|
||||
option.
|
||||
|
||||
``builders``
|
||||
|
||||
A comma separated list of builders to run. For example, to build both HTML
|
||||
and man page documentation, you would define the following in your
|
||||
`setup.cfg`:
|
||||
``setup.cfg``:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
|
|
@ -261,95 +310,63 @@ option.
|
|||
``builder`` option. You should use this option instead. Refer to the
|
||||
`Sphinx documentation`_ for more information.
|
||||
|
||||
For information on the remaining options, refer to the `Sphinx
|
||||
documentation`_. In addition, the ``autodoc_index_modules``,
|
||||
``autodoc_tree_index_modules``, ``autodoc_exclude_modules`` and
|
||||
``autodoc_tree_excludes`` options in the ``pbr`` section will affect the output
|
||||
of the automatic module documentation generation.
|
||||
|
||||
.. versionchanged:: 3.0
|
||||
|
||||
The ``build_sphinx`` plugin used to default to building both HTML and man
|
||||
page output. This is no longer the case, and you should explicitly set
|
||||
``builders`` to ``html man`` if you wish to retain this behavior.
|
||||
For information on the remaining options, refer to the `Sphinx documentation`_.
|
||||
In addition, the ``autodoc_index_modules``, ``autodoc_tree_index_modules``,
|
||||
``autodoc_exclude_modules`` and ``autodoc_tree_excludes`` options :ref:`in the
|
||||
pbr section <pbr-setup-cfg>` will affect the output of the automatic module
|
||||
documentation generation.
|
||||
|
||||
.. _Sphinx documentation: http://www.sphinx-doc.org/en/stable/setuptools.html
|
||||
|
||||
entry_points
|
||||
~~~~~~~~~~~~
|
||||
|
||||
The ``entry_points`` section defines entry points for generated console scripts
|
||||
and python libraries. This is actually provided by setuptools_ but is
|
||||
documented here owing to its importance.
|
||||
|
||||
The general syntax of specifying entry points is a top level name indicating
|
||||
the entry point group name, followed by one or more key value pairs naming
|
||||
the entry point to be installed. For instance::
|
||||
|
||||
[entry_points]
|
||||
console_scripts =
|
||||
pbr = pbr.cmd:main
|
||||
pbr.config.drivers =
|
||||
plain = pbr.cfg.driver:Plain
|
||||
fancy = pbr.cfg.driver:Fancy
|
||||
|
||||
Will cause a console script called `pbr` to be installed that executes the
|
||||
`main` function found in `pbr.cmd`. Additionally, two entry points will be
|
||||
installed for `pbr.config.drivers`, one called `plain` which maps to the
|
||||
`Plain` class in `pbr.cfg.driver` and one called `fancy` which maps to the
|
||||
`Fancy` class in `pbr.cfg.driver`.
|
||||
|
||||
Requirements
|
||||
------------
|
||||
|
||||
Requirement files should be given one of the below names. This order is also
|
||||
the order that the requirements are tried in (where `N` is the Python major
|
||||
version number used to install the package):
|
||||
Requirements files are used in place of the ``install_requires`` and
|
||||
``extras_require`` attributes. Requirement files should be given one of the
|
||||
below names. This order is also the order that the requirements are tried in
|
||||
(where ``N`` is the Python major version number used to install the package):
|
||||
|
||||
* requirements-pyN.txt
|
||||
* tools/pip-requires-py3
|
||||
* requirements.txt
|
||||
* tools/pip-requires
|
||||
* ``requirements-pyN.txt``
|
||||
* ``tools/pip-requires-py3``
|
||||
* ``requirements.txt``
|
||||
* ``tools/pip-requires``
|
||||
|
||||
Only the first file found is used to install the list of packages it contains.
|
||||
|
||||
.. note::
|
||||
|
||||
The 'requirements-pyN.txt' file is deprecated - 'requirements.txt' should
|
||||
be universal. You can use `Environment markers`_ for this purpose.
|
||||
The ``requirements-pyN.txt`` file is deprecated - ``requirements.txt``
|
||||
should be universal. You can use `Environment markers`_ for this purpose.
|
||||
|
||||
.. _extra-requirements:
|
||||
|
||||
Extra requirements
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Groups of optional dependencies, or `"extra" requirements`_, can be described
|
||||
in your `setup.cfg`, rather than needing to be added to `setup.py`. An example
|
||||
(which also demonstrates the use of environment markers) is shown below.
|
||||
Groups of optional dependencies, or `"extra" requirements`__, can be described
|
||||
in your ``setup.cfg``, rather than needing to be added to ``setup.py``. An
|
||||
example (which also demonstrates the use of environment markers) is shown
|
||||
below.
|
||||
|
||||
.. _"extra" requirements:
|
||||
https://www.python.org/dev/peps/pep-0426/#extras-optional-dependencies
|
||||
__ https://www.python.org/dev/peps/pep-0426/#extras-optional-dependencies
|
||||
|
||||
Environment markers
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Environment markers are `conditional dependencies`_ which can be added to the
|
||||
requirements (or to a group of extra requirements) automatically, depending
|
||||
on the environment the installer is running in. They can be added to
|
||||
requirements in the requirements file, or to extras defined in `setup.cfg`,
|
||||
but the format is slightly different for each.
|
||||
|
||||
.. _conditional dependencies:
|
||||
https://www.python.org/dev/peps/pep-0426/#environment-markers
|
||||
Environment markers are `conditional dependencies`__ which can be added to the
|
||||
requirements (or to a group of extra requirements) automatically, depending on
|
||||
the environment the installer is running in. They can be added to requirements
|
||||
in the requirements file, or to extras defined in ``setup.cfg``, but the format
|
||||
is slightly different for each.
|
||||
|
||||
For ``requirements.txt``::
|
||||
|
||||
argparse; python_version=='2.6'
|
||||
|
||||
This will result in the package depending on ``argparse`` only if it's being
|
||||
installed into Python 2.6
|
||||
installed into Python 2.6.
|
||||
|
||||
For extras specified in `setup.cfg`, add an ``extras`` section. For instance,
|
||||
For extras specified in ``setup.cfg``, add an ``extras`` section. For instance,
|
||||
to create two groups of extra requirements with additional constraints on the
|
||||
environment, you can use::
|
||||
|
||||
|
|
@ -361,31 +378,15 @@ environment, you can use::
|
|||
testing =
|
||||
quux:python_version=='2.7'
|
||||
|
||||
__ https://www.python.org/dev/peps/pep-0426/#environment-markers
|
||||
|
||||
Testing
|
||||
-------
|
||||
|
||||
`pbr` overrides the ``setuptools`` hook ``test`` (i.e. ``setup.py test``). The
|
||||
following sequence is followed:
|
||||
.. deprecated:: 4.0
|
||||
|
||||
#. If a ``.testr.conf`` file exists and `testrepository
|
||||
<https://pypi.python.org/pypi/testrepository>`__ is installed, `pbr`
|
||||
will use it as the test runner. See the ``testr`` documentation
|
||||
for more details.
|
||||
|
||||
.. note::
|
||||
|
||||
This is separate to ``setup.py testr`` (note the extra ``r``) which
|
||||
is provided directly by the ``testrepository`` package. Be careful
|
||||
as there is some overlap of command arguments.
|
||||
|
||||
#. Although deprecated, if ``[nosetests]`` is defined in ``setup.cfg``
|
||||
and `nose <http://nose.readthedocs.io/en/latest/>`__ is installed,
|
||||
the ``nose`` runner will be used.
|
||||
|
||||
#. In other cases no override will be installed and the ``test``
|
||||
command will revert to `setuptools
|
||||
<http://setuptools.readthedocs.io/en/latest/setuptools.html#test-build-package-and-run-a-unittest-suite>`__.
|
||||
As described in :doc:`/user/features`, *pbr* may override the ``test`` command
|
||||
depending on the test runner used.
|
||||
|
||||
A typical usage would be in ``tox.ini`` such as::
|
||||
|
||||
|
|
@ -404,10 +405,8 @@ A typical usage would be in ``tox.ini`` such as::
|
|||
commands =
|
||||
python setup.py test --testr-args='{posargs}'
|
||||
|
||||
The argument ``--coverage`` will set ``PYTHON`` to ``coverage run`` to
|
||||
produce a coverage report. ``--coverage-package-name`` can be used to
|
||||
modify or narrow the packages traced.
|
||||
The argument ``--coverage`` will set ``PYTHON`` to ``coverage run`` to produce
|
||||
a coverage report. ``--coverage-package-name`` can be used to modify or narrow
|
||||
the packages traced.
|
||||
|
||||
.. _d2to1: https://pypi.python.org/pypi/d2to1
|
||||
.. _PEP 426: http://legacy.python.org/dev/peps/pep-0426/
|
||||
.. _OpenStack: https://www.openstack.org/
|
||||
.. _setuptools: http://www.sphinx-doc.org/en/stable/setuptools.html
|
||||
|
|
|
|||
Loading…
Reference in New Issue