⇪ Bump Sphinx to v3.2.0

This change also includes all the fixes necessary for Sphinx 3 not to
explode during the build in the strict mode. In particular, it now barks
on the case-sensitive `:term:` targets that don't match.

Author: webknjaz

requirements.txt

@@ -1,4 +1,4 @@
-sphinx==2.1.2
+sphinx==3.2.0
 sphinx-autobuild==0.7.1
 git+https://github.com/python/python-docs-theme.git#egg=python-docs-theme
 git+https://github.com/pypa/pypa-docs-theme.git#egg=pypa-docs-theme

source/glossary.rst

@@ -27,7 +27,7 @@ Glossary
     Distribution Package
 
         A versioned archive file that contains Python :term:`packages <Import
-        Package>`, :term:`modules <module>`, and other resource files that are
+        Package>`, :term:`modules <Module>`, and other resource files that are
         used to distribute a :term:`Release`. The archive file is what an
         end-user will download from the internet and install.
 
@@ -49,7 +49,7 @@ Glossary
 
     Extension Module
 
-        A :term:`module` written in the low-level language of the Python implementation:
+        A :term:`Module` written in the low-level language of the Python implementation:
         C/C++ for Python, Java for Jython. Typically contained in a single
         dynamically loadable pre-compiled file, e.g.  a shared object (.so) file
         for Python extensions on Unix, a DLL (given the .pyd extension) for
@@ -121,7 +121,7 @@ Glossary
 
     Pure Module
 
-        A :term:`module` written in Python and contained in a single ``.py`` file (and
+        A :term:`Module` written in Python and contained in a single ``.py`` file (and
         possibly associated ``.pyc`` and/or ``.pyo`` files).
 
 
@@ -152,7 +152,7 @@ Glossary
 
     pyproject.toml
 
-        The tool-agnostic :term:`project` specification file.
+        The tool-agnostic :term:`Project` specification file.
         Defined in :pep:`518`.
 
     Release

source/guides/installing-scientific-packages.rst

@@ -76,7 +76,7 @@ environments. Allowing access to distributions installed into the system Python
 when using virtual environments is a common approach to working around this
 limitation.
 
-The :term:`wheel` project also provides a :command:`wheel convert` subcommand that can
+The :term:`Wheel` project also provides a :command:`wheel convert` subcommand that can
 convert a Windows :command:`bdist_wininst` installer to a wheel.
 
 .. preserve old links to this heading

source/guides/migrating-to-pypi-org.rst

@@ -3,7 +3,7 @@
 Migrating to PyPI.org
 =====================
 
-:term:`PyPI.org` is the new, rewritten version of PyPI that has replaced the
+:term:`pypi.org` is the new, rewritten version of PyPI that has replaced the
 legacy PyPI code base. It is the default version of PyPI that people are
 expected to use. These are the tools and processes that people will need to
 interact with ``PyPI.org``.

source/overview.rst

@@ -79,7 +79,7 @@ Python source distributions
 
 If your code consists of multiple Python files, it's usually organized
 into a directory structure. Any directory containing Python files can
-comprise an :term:`import package`.
+comprise an :term:`Import Package`.
 
 Because packages consist of multiple files, they are harder to
 distribute. Most protocols support transferring only one file at a
@@ -90,7 +90,7 @@ to guarantee code integrity at the destination.
 So long as your code contains nothing but pure Python code, and you
 know your deployment environment supports your version of Python, then
 you can use Python's native packaging tools to create a *source*
-:term:`distribution package`, or *sdist* for short.
+:term:`Distribution Package`, or *sdist* for short.
 
 Python's *sdists* are compressed archives (``.tar.gz`` files)
 containing one or more packages or modules. If your code is
@@ -124,7 +124,7 @@ in C, C++, Fortran, Rust, and other languages.
 
 Not all developers have the right tools or experiences to build these
 components written in these compiled languages, so Python created the
-:term:`wheel`, a package format designed to ship libraries with
+:term:`Wheel`, a package format designed to ship libraries with
 compiled artifacts. In fact, Python's package installer, ``pip``,
 always prefers wheels because installation is always faster, so even
 pure-Python packages work better with wheels.

source/tutorials/packaging-projects.rst

@@ -10,7 +10,7 @@ A simple project
 ----------------
 
 This tutorial uses a simple project named ``example_pkg``. If you are unfamiliar
-with Python's modules and :term:`import packages <import package>`, take a few
+with Python's modules and :term:`import packages <Import Package>`, take a few
 minutes to read over the `Python documentation for packages and modules`_. Even if you already have a project that you want to package up, we recommend following this tutorial as-is using this example package and then trying with your own package.
 
 To create this project locally, create the following file structure:
@@ -112,7 +112,7 @@ minimal set:
   will just be a link to GitHub, GitLab, Bitbucket, or similar code hosting
   service.
 - ``packages`` is a list of all Python :term:`import packages <Import
-  Package>` that should be included in the :term:`distribution package`.
+  Package>` that should be included in the :term:`Distribution Package`.
   Instead of listing each package manually, we can use :func:`find_packages`
   to automatically discover all packages and subpackages. In this case, the
   list of packages will be ``example_pkg`` as that's the only package present.
@@ -181,8 +181,8 @@ MIT license:
 Generating distribution archives
 --------------------------------
 
-The next step is to generate :term:`distribution packages <distribution
-package>` for the package. These are archives that are uploaded to the Package
+The next step is to generate :term:`distribution packages <Distribution
+Package>` for the package. These are archives that are uploaded to the Package
 Index and can be installed by :ref:`pip`.
 
 Make sure you have the latest versions of ``setuptools`` and ``wheel``
@@ -217,8 +217,8 @@ files in the :file:`dist` directory:
   https://github.com/pypa/packaging-problems/issues/new?title=Trouble+following+packaging+libraries+tutorial
 
 
-The ``tar.gz`` file is a :term:`source archive` whereas the ``.whl`` file is a
-:term:`built distribution`. Newer :ref:`pip` versions preferentially install
+The ``tar.gz`` file is a :term:`Source Archive` whereas the ``.whl`` file is a
+:term:`Built Distribution`. Newer :ref:`pip` versions preferentially install
 built distributions, but will fall back to source archives if needed. You
 should always upload a source archive and provide built archives for the
 platforms your project is compatible with. In this case, our example package is
@@ -322,7 +322,8 @@ and from the interpreter shell import the package:
 
     >>> import example_pkg
 
-Note that the :term:`import package` is ``example_pkg`` regardless of what name you gave your :term:`distribution package`
+Note that the :term:`Import Package` is ``example_pkg`` regardless of what
+name you gave your :term:`Distribution Package`
 in :file:`setup.py` (in this case, ``example-pkg-YOUR-USERNAME-HERE``).
 
 Next steps