Add PyPI extlink alias

requirements.txt

@@ -3,5 +3,6 @@ sphinx==7.2.6
 sphinx-autobuild==2021.3.14
 sphinx-inline-tabs==2023.4.21
 sphinx-copybutton==0.5.2
+sphinx-issues==5.0.1
 sphinx-toolbox==3.5.0
 sphinx-jsonschema==1.19.1

source/conf.py

@@ -28,6 +28,7 @@
 
 extensions = [
     "pug_sphinx_extensions",
+    "sphinx_issues",
     "sphinx.ext.extlinks",
     "sphinx.ext.intersphinx",
     "sphinx.ext.todo",
@@ -194,13 +195,13 @@
 github_sponsors_url = f"{github_url}/sponsors"
 
 extlinks = {
-    "issue": (f"{github_repo_issues_url}/%s", "#%s"),
-    "pr": (f"{github_repo_url}/pull/%s", "PR #%s"),
-    "commit": (f"{github_repo_url}/commit/%s", "%s"),
     "gh": (f"{github_url}/%s", "GitHub: %s"),
-    "user": (f"{github_sponsors_url}/%s", "@%s"),
 }
 
+# -- Options for sphinx_issues --------------------------------------------------------
+
+issues_default_group_project = github_repo_slug
+
 # -- Options for intersphinx ----------------------------------------------------------
 # https://www.sphinx-doc.org/en/master/usage/extensions/intersphinx.html#configuration
 

source/discussions/deploying-python-applications.rst

@@ -57,7 +57,7 @@ Windows
 Pynsist
 ^^^^^^^
 
-`Pynsist <https://pypi.org/project/pynsist>`__ is a tool that bundles Python
+:pypi:`Pynsist <pynsist>` is a tool that bundles Python
 programs together with the Python-interpreter into a single installer based on
 NSIS. In most cases, packaging only requires the user to choose a version of
 the Python-interpreter and declare the dependencies of the program. The tool
@@ -88,7 +88,7 @@ Windows
 py2exe
 ^^^^^^
 
-`py2exe <https://pypi.org/project/py2exe/>`__ is a distutils extension which
+:pypi:`py2exe` is a distutils extension which
 allows to build standalone Windows executable programs (32-bit and 64-bit)
 from Python scripts. Python versions included in the official development
 cycle are supported (refers to `Status of Python branches`__). py2exe can
@@ -105,7 +105,7 @@ macOS
 py2app
 ^^^^^^
 
-`py2app <https://pypi.org/project/py2app/>`__ is a Python setuptools
+:pypi:`py2app` is a Python setuptools
 command which will allow you to make standalone macOS application
 bundles and plugins from Python scripts. Note that py2app MUST be used
 on macOS to build applications, it cannot create Mac applications on other
@@ -117,7 +117,7 @@ Unix (including Linux and macOS)
 pex
 ^^^
 
-`pex <https://pypi.org/project/pex/>`__ is  a library for generating .pex
+:pypi:`pex` is  a library for generating .pex
 (Python EXecutable) files which are executable Python environments in the
 spirit of virtualenvs. pex is an expansion upon the ideas outlined in :pep:`441`
 and makes the deployment of Python applications as simple as cp. pex files may

source/discussions/distribution-package-vs-import-package.rst

@@ -57,7 +57,7 @@ install the PyPI package ``foo`` if you see ``import foo``; this may install an
 unintended, and potentially even malicious package.)
 
 A distribution package could provide an import package with a different
-name. An example of this is the popular Pillow_ library for image
+name. An example of this is the popular :pypi:`Pillow` library for image
 processing. Its distribution package name is ``Pillow``, but it provides
 the import package ``PIL``. This is for historical reasons: Pillow
 started as a fork of the PIL library, thus it kept the import name
@@ -72,7 +72,7 @@ Import packages with the same name can be provided by several
 distribution packages. Again, forks are a common reason for this.
 
 Conversely, a distribution package can provide several import packages,
-although this is less common. An example is the attrs_ distribution
+although this is less common. An example is the :pypi:`attrs` distribution
 package, which provides both an ``attrs`` import package with a newer
 API, and an ``attr`` import package with an older but supported API.
 
@@ -106,5 +106,3 @@ precise rules are given in the :ref:`name normalization specification
 
 .. _distro: https://en.wikipedia.org/wiki/Linux_distribution
 .. _PyPI: https://pypi.org
-.. _Pillow: https://pypi.org/project/Pillow
-.. _attrs: https://pypi.org/project/attrs

source/discussions/downstream-packaging.rst

@@ -126,8 +126,8 @@ in their installed packages. This has the added advantage of permitting users to
 run tests after installing them, for example to check for regressions
 after upgrading a dependency. Yet another approach is to split tests or test
 data into a separate Python package. Such an approach was taken by
-the cryptography_ project, with the large test vectors being split
-to cryptography-vectors_ package.
+the :pypi:`cryptography` project, with the large test vectors being split
+to :pypi:`cryptography-vectors` package.
 
 A good idea is to use your source distribution in the release workflow.
 For example, the :ref:`build` tool does exactly that — it first builds a source
@@ -351,9 +351,9 @@ Some specific suggestions are:
   of the installed package!
 
 - Make the test suite work offline. Mock network interactions, using
-  packages such as responses_ or vcrpy_. If that is not possible, make it
+  packages such as :pypi:`responses` or :pypi:`vcrpy`. If that is not possible, make it
   possible to easily disable the tests using Internet access, e.g. via a pytest_
-  marker. Use pytest-socket_ to verify that your tests work offline. This
+  marker. Use :pypi:`pytest-socket` to verify that your tests work offline. This
   often makes your own test workflows faster and more reliable as well.
 
 - Make your tests work without a specialized setup, or perform the necessary
@@ -389,14 +389,14 @@ Some specific suggestions are:
 
 - If your test suite takes significant time to run, support testing
   in parallel. Downstreams often maintain a large number of packages,
-  and testing them all takes a lot of time. Using pytest-xdist_ can help them
+  and testing them all takes a lot of time. Using :pypi:`pytest-xdist` can help them
   avoid bottlenecks.
 
 - Ideally, support running your test suite via ``pytest``. pytest_ has many
   command-line arguments that are truly helpful to downstreams, such as
   the ability to conveniently deselect tests, rerun flaky tests
-  (via pytest-rerunfailures_), add a timeout to prevent tests from hanging
-  (via pytest-timeout_) or run tests in parallel (via pytest-xdist_).
+  (via :pypi:`pytest-rerunfailures`), add a timeout to prevent tests from hanging
+  (via :pypi:`pytest-timeout`) or run tests in parallel (via :pypi:`pytest-xdist`).
   Note that test suites don't need to be *written* with ``pytest`` to be
   *executed* with ``pytest``: ``pytest`` is able to find and execute almost
   all test cases that are compatible with the standard library's ``unittest``
@@ -468,14 +468,6 @@ as well. Some specific suggestions are:
   to make it easier to cherry-pick changes to earlier releases when necessary.
 
 
-.. _responses: https://pypi.org/project/responses/
-.. _vcrpy: https://pypi.org/project/vcrpy/
-.. _pytest-socket: https://pypi.org/project/pytest-socket/
-.. _pytest-xdist: https://pypi.org/project/pytest-xdist/
 .. _pytest: https://pytest.org/
-.. _pytest-rerunfailures: https://pypi.org/project/pytest-rerunfailures/
-.. _pytest-timeout: https://pypi.org/project/pytest-timeout/
 .. _Django: https://www.djangoproject.com/
 .. _NumPy: https://numpy.org/
-.. _cryptography: https://pypi.org/project/cryptography/
-.. _cryptography-vectors: https://pypi.org/project/cryptography-vectors/

source/flow.rst

@@ -68,12 +68,9 @@ format`_.
 At a minimum, the :file:`pyproject.toml` file needs a ``[build-system]`` table
 specifying your build tool. There are many build tools available, including
 but not limited to :ref:`flit`, :ref:`hatch`, :ref:`pdm`, :ref:`poetry`,
-:ref:`setuptools`, `trampolim`_, and `whey`_. Each tool's documentation will
+:ref:`setuptools`, :pypi:`trampolim`, and :pypi:`whey`. Each tool's documentation will
 show what to put in the ``[build-system]`` table.
 
-.. _trampolim: https://pypi.org/project/trampolim/
-.. _whey: https://pypi.org/project/whey/
-
 For example, here is a table for using :ref:`hatch`:
 
 .. code-block:: toml

source/guides/creating-and-discovering-plugins.rst

@@ -19,7 +19,7 @@ Using naming convention
 
 If all of the plugins for your application follow the same naming convention,
 you can use :func:`pkgutil.iter_modules` to discover all of the top-level
-modules that match the naming convention. For example, `Flask`_ uses the
+modules that match the naming convention. For example, :pypi:`Flask` uses the
 naming convention ``flask_{plugin_name}``. If you wanted to automatically
 discover all of the Flask plugins installed:
 
@@ -35,7 +35,7 @@ discover all of the Flask plugins installed:
         if name.startswith('flask_')
     }
 
-If you had both the `Flask-SQLAlchemy`_ and `Flask-Talisman`_ plugins installed
+If you had both the :pypi:`Flask-SQLAlchemy` and :pypi:`Flask-Talisman <flask-talisman>` plugins installed
 then ``discovered_plugins`` would be:
 
 .. code-block:: python
@@ -49,11 +49,6 @@ Using naming convention for plugins also allows you to query
 the Python Package Index's :ref:`simple repository API <simple-repository-api>`
 for all packages that conform to your naming convention.
 
-.. _Flask: https://pypi.org/project/Flask/
-.. _Flask-SQLAlchemy: https://pypi.org/project/Flask-SQLAlchemy/
-.. _Flask-Talisman: https://pypi.org/project/flask-talisman
-
-
 Using namespace packages
 ========================
 

source/guides/dropping-older-python-versions.rst

@@ -129,10 +129,9 @@ Each version compatibility change should have its own release.
 
 .. tip::
 
-        When dropping a Python version, it might also be rewarding to upgrade the project's code syntax generally, apart from updating the versions used in visible places (like the testing environment). Tools like pyupgrade_ or `ruff <https://docs.astral.sh/ruff/linter/>`_ can automate some of this work.
+        When dropping a Python version, it might also be rewarding to upgrade the project's code syntax generally, apart from updating the versions used in visible places (like the testing environment). Tools like :pypi:`pyupgrade` or `ruff <https://docs.astral.sh/ruff/linter/>`_ can automate some of this work.
 
 .. _discourse-discussion: https://discuss.python.org/t/requires-python-upper-limits/12663
-.. _pyupgrade: https://pypi.org/project/pyupgrade/
 .. _dependency-management: https://setuptools.pypa.io/en/latest/userguide/dependency_management.html#python-requirement
 
 .. [#] Support for the Metadata 1.2 specification has been added in Pip 9.0.

source/guides/installing-using-pip-and-virtual-environments.rst

@@ -201,7 +201,7 @@ Install a package
 ~~~~~~~~~~~~~~~~~
 
 For example, let's install the
-`Requests`_ library from the :term:`Python Package Index (PyPI)`:
+:pypi:`Requests <requests>` library from the :term:`Python Package Index (PyPI)`:
 
 .. tab:: Unix/macOS
 
@@ -232,9 +232,6 @@ pip should download requests and all of its dependencies and install them:
     Installing collected packages: chardet, urllib3, certifi, idna, requests
     Successfully installed certifi-2017.7.27.1 chardet-3.0.4 idna-2.6 requests-2.18.4 urllib3-1.22
 
-.. _Requests: https://pypi.org/project/requests/
-
-
 Install a specific package version
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 

source/guides/supporting-multiple-python-versions.rst

@@ -86,18 +86,18 @@ with a single-source strategy, there are a number of options.
 Tools for single-source Python packages
 ----------------------------------------
 
-`six <https://pypi.org/project/six/>`_ is a tool developed by Benjamin Peterson
-for wrapping over the differences between Python 2 and Python 3. The six_
+:pypi:`six` is a tool developed by Benjamin Peterson
+for wrapping over the differences between Python 2 and Python 3. The :pypi:`six`
 package has enjoyed widespread use and may be regarded as a reliable way to
 write a single-source Python module that can be use in both Python 2 and 3.
-The six_ module can be used from as early as Python 2.5. A tool called
-`modernize <https://pypi.org/project/modernize>`_, developed by Armin
+The :pypi:`six` module can be used from as early as Python 2.5. A tool called
+:pypi:`modernize`, developed by Armin
 Ronacher, can be used to automatically apply the code modifications provided
-by six_.
+by :pypi:`six`.
 
-Similar to six_, `python-future <http://python-future.org/overview.html>`_ is
+Similar to :pypi:`six`, `python-future <http://python-future.org/overview.html>`_ is
 a package that provides a compatibility layer between Python 2 and Python 3
-source code; however, unlike six_, this package aims to provide
+source code; however, unlike :pypi:`six`, this package aims to provide
 interoperability between Python 2 and Python 3 with a language syntax that
 matches one of the two Python versions: one may
 use
@@ -107,12 +107,12 @@ use
 
 Because of the bi-directionality, python-future_ offers a pathway to
 converting a Python 2 package to Python 3 syntax module-by-module. However, in
-contrast to six_, python-future_ is supported only from Python 2.6. Similar to
-modernize_ for six_, python-future_ comes with two scripts called ``futurize``
+contrast to :pypi:`six`, python-future_ is supported only from Python 2.6. Similar to
+:pypi:`modernize` for :pypi:`six`, python-future_ comes with two scripts called ``futurize``
 and ``pasteurize`` that can be applied to either a Python 2 module or a Python
 3 module respectively.
 
-Use of six_ or python-future_ adds an additional runtime dependency to your
+Use of :pypi:`six` or python-future_ adds an additional runtime dependency to your
 package: with python-future_, the ``futurize`` script can be called with the
 ``--stage1`` option to apply only the changes that Python 2.6+ already
 provides for forward-compatibility to Python 3. Any remaining compatibility

source/guides/tool-recommendations.rst

@@ -74,11 +74,11 @@ in alphabetical order:
 - :doc:`Flit-core <flit:pyproject_toml>` -- developed with but separate from :ref:`Flit`.
   A minimal and opinionated build backend. It does not support plugins.
 
-- Hatchling_ -- developed with but separate from :ref:`Hatch`. Supports plugins.
+- :pypi:`Hatchling <hatchling>` -- developed with but separate from :ref:`Hatch`. Supports plugins.
 
 - PDM-backend_ -- developed with but separate from :ref:`PDM`. Supports plugins.
 
-- Poetry-core_ -- developed with but separate from :ref:`Poetry`. Supports
+- :pypi:`Poetry-core <poetry-core>` -- developed with but separate from :ref:`Poetry`. Supports
   plugins.
 
   Unlike other backends on this list, Poetry-core does not support the standard
@@ -185,6 +185,4 @@ alphabetical order:
 - :doc:`tox <tox:index>`.
 
 
-.. _hatchling: https://pypi.org/project/hatchling/
 .. _pdm-backend: https://backend.pdm-project.org
-.. _poetry-core: https://pypi.org/project/poetry-core/

source/guides/writing-pyproject-toml.rst

@@ -255,7 +255,7 @@ an email address.
 ---------------
 
 This should be a one-line description of your project, to show as the "headline"
-of your project page on PyPI (`example <pypi-pip_>`_), and other places such as
+of your project page on PyPI (:pypi:`example <pip>`), and other places such as
 lists of search results (`example <pypi-search-pip_>`_).
 
 .. code-block:: toml
@@ -585,7 +585,6 @@ A full example
 .. _gfm: https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax
 .. _setuptools: https://setuptools.pypa.io
 .. _poetry: https://python-poetry.org
-.. _pypi-pip: https://pypi.org/project/pip
 .. _pypi-search-pip: https://pypi.org/search?q=pip
 .. _classifier-list: https://pypi.org/classifiers
 .. _requires-python-blog-post: https://iscinumpy.dev/post/bound-version-constraints/#pinning-the-python-version-is-special