Merge branch 'main' into feat/project_urls

Author: webknjaz

source/guides/analyzing-pypi-package-downloads.rst

@@ -68,10 +68,10 @@ the `BigQuery quickstart guide
 Data schema
 -----------
 
-Linehaul writes an entry in a ``the-psf.pypi.file_downloads`` table for each
+Linehaul writes an entry in a ``bigquery-public-data.pypi.file_downloads`` table for each
 download. The table contains information about what file was downloaded and how
 it was downloaded. Some useful columns from the `table schema
-<https://console.cloud.google.com/bigquery?pli=1&p=the-psf&d=pypi&t=file_downloads&page=table>`__
+<https://console.cloud.google.com/bigquery?pli=1&p=bigquery-public-data&d=pypi&t=file_downloads&page=table>`__
 include:
 
 +------------------------+-----------------+-----------------------------+
@@ -108,7 +108,7 @@ The following query counts the total number of downloads for the project
 
     #standardSQL
     SELECT COUNT(*) AS num_downloads
-    FROM `the-psf.pypi.file_downloads`
+    FROM `bigquery-public-data.pypi.file_downloads`
     WHERE file.project = 'pytest'
       -- Only query the last 30 days of history
       AND DATE(timestamp)
@@ -118,7 +118,7 @@ The following query counts the total number of downloads for the project
 +---------------+
 | num_downloads |
 +===============+
-| 20531925      |
+| 26190085      |
 +---------------+
 
 To only count downloads from pip, filter on the ``details.installer.name``
@@ -128,7 +128,7 @@ column.
 
     #standardSQL
     SELECT COUNT(*) AS num_downloads
-    FROM `the-psf.pypi.file_downloads`
+    FROM `bigquery-public-data.pypi.file_downloads`
     WHERE file.project = 'pytest'
       AND details.installer.name = 'pip'
       -- Only query the last 30 days of history
@@ -139,7 +139,7 @@ column.
 +---------------+
 | num_downloads |
 +===============+
-| 19391645      |
+| 24334215      |
 +---------------+
 
 Package downloads over time
@@ -154,7 +154,7 @@ filtering by this column reduces corresponding costs.
     SELECT
       COUNT(*) AS num_downloads,
       DATE_TRUNC(DATE(timestamp), MONTH) AS `month`
-    FROM `the-psf.pypi.file_downloads`
+    FROM `bigquery-public-data.pypi.file_downloads`
     WHERE
       file.project = 'pytest'
       -- Only query the last 6 months of history
@@ -192,7 +192,7 @@ query processes over 500 GB of data.
     SELECT
       REGEXP_EXTRACT(details.python, r"[0-9]+\.[0-9]+") AS python_version,
       COUNT(*) AS num_downloads,
-    FROM `the-psf.pypi.file_downloads`
+    FROM `bigquery-public-data.pypi.file_downloads`
     WHERE
       -- Only query the last 6 months of history
       DATE(timestamp)
@@ -204,17 +204,17 @@ query processes over 500 GB of data.
 +--------+---------------+
 | python | num_downloads |
 +========+===============+
-| 3.7    | 12990683561   |
+| 3.7    | 18051328726   |
 +--------+---------------+
-| 3.6    | 9035598511    |
+| 3.6    | 9635067203    |
 +--------+---------------+
-| 2.7    | 8467785320    |
+| 3.8    | 7781904681    |
 +--------+---------------+
-| 3.8    | 4581627740    |
+| 2.7    | 6381252241    |
 +--------+---------------+
-| 3.5    | 2412533601    |
+| null   | 2026630299    |
 +--------+---------------+
-| null   | 1641456718    |
+| 3.5    | 1894153540    |
 +--------+---------------+
 
 Caveats
@@ -251,7 +251,7 @@ the official Python client library for BigQuery.
 
     query_job = client.query("""
     SELECT COUNT(*) AS num_downloads
-    FROM `the-psf.pypi.file_downloads`
+    FROM `bigquery-public-data.pypi.file_downloads`
     WHERE file.project = 'pytest'
       -- Only query the last 30 days of history
       AND DATE(timestamp)
@@ -303,7 +303,7 @@ References
 .. [#] `PyPI Download Counts deprecation email <https://mail.python.org/pipermail/distutils-sig/2013-May/020855.html>`__
 .. [#] `PyPI BigQuery dataset announcement email <https://mail.python.org/pipermail/distutils-sig/2016-May/028986.html>`__
 
-.. _public PyPI download statistics dataset: https://console.cloud.google.com/bigquery?p=the-psf&d=pypi&page=dataset
+.. _public PyPI download statistics dataset: https://console.cloud.google.com/bigquery?p=bigquery-public-data&d=pypi&page=dataset
 .. _bandersnatch: /key_projects/#bandersnatch
 .. _Google BigQuery: https://cloud.google.com/bigquery
 .. _BigQuery web UI: https://console.cloud.google.com/bigquery

source/guides/distributing-packages-using-setuptools.rst

@@ -12,11 +12,10 @@ The section does *not* aim to cover best practices for Python project
 development as a whole.  For example, it does not provide guidance or tool
 recommendations for version control, documentation, or testing.
 
-For more reference material, see `Building and Distributing Packages
-<https://setuptools.readthedocs.io/en/latest/setuptools.html>`_ in the
-:ref:`setuptools` docs, but note that some advisory content there may be
-outdated. In the event of conflicts, prefer the advice in the Python
-Packaging User Guide.
+For more reference material, see :std:doc:`Building and Distributing
+Packages <userguide/index>` in the :ref:`setuptools` docs, but note
+that some advisory content there may be outdated. In the event of
+conflicts, prefer the advice in the Python Packaging User Guide.
 
 .. contents:: Contents
    :local:
@@ -445,9 +444,9 @@ The value must be a mapping from package name to a list of relative path names
 that should be copied into the package. The paths are interpreted as relative to
 the directory containing the package.
 
-For more information, see `Including Data Files
-<https://setuptools.readthedocs.io/en/latest/setuptools.html#including-data-files>`_
-from the `setuptools docs <https://setuptools.readthedocs.io>`_.
+For more information, see :std:doc:`Including Data Files
+<setuptools:userguide/datafiles>` from the
+:std:doc:`setuptools docs <setuptools:index>`.
 
 
 .. _`Data Files`:
@@ -652,7 +651,7 @@ maintained by a redistributor.
 A local version identifier takes the form ``<public version identifier>+<local version label>``.
 For example::
 
-   1.2.0.dev1+hg.5.b11e5e6f0b0b  # 5th VCS commmit since 1.2.0.dev1 release
+   1.2.0.dev1+hg.5.b11e5e6f0b0b  # 5th VCS commit since 1.2.0.dev1 release
    1.2.1+fedora.4                # Package with downstream Fedora patches applied
 
 

source/guides/hosting-your-own-index.rst

@@ -26,7 +26,7 @@ all repositories using a valid HTTPS setup.
 
 The directory layout is fairly simple, within a root directory you need to
 create a directory for each project. This directory should be the normalized
-name (as defined by PEP 503) of the project. Within each of these directories
+name (as defined by :pep:`503`) of the project. Within each of these directories
 simply place each of the downloadable files. If you have the projects "Foo"
 (with the versions 1.0 and 2.0) and "bar" (with the version 0.1) You should
 end up with a structure that looks like::
@@ -46,7 +46,7 @@ instruct users to add the URL to their installer's configuration.
 ----
 
 .. [1] For complete documentation of the simple repository protocol, see
-       PEP 503.
+       :pep:`503`.
 
 
 .. _devpi: http://doc.devpi.net/latest/

source/key_projects.rst

@@ -43,7 +43,7 @@ build
 User IRC:`#pypa <https://webchat.freenode.net/?channels=%23pypa>`__ |
 Dev IRC:`#pypa-dev <https://webchat.freenode.net/?channels=%23pypa-dev>`__
 
-``build`` is a PEP-517 compatible Python package builder. It provides a CLI to
+``build`` is a :pep:`517` compatible Python package builder. It provides a CLI to
 build packages, as well as a Python API.
 
 

source/specifications/platform-compatibility-tags.rst

@@ -33,12 +33,12 @@ The scheme defined in :pep:`425` is insufficient for public distribution of
 wheel files (and \*nix wheel files in general) to Linux platforms, due to the
 large ecosystem of Linux platforms and subtle differences between them.
 
-Instead, :pep:`513` defines the ``manylinux`` standard, which represents a
+Instead, :pep:`600` defines the ``manylinux`` standard, which represents a
 common subset of Linux platforms, and allows building wheels tagged with the
 ``manylinux`` platform tag which can be used across most common Linux
 distributions.
 
-There are multiple iterations of the ``manylinux`` specification, each
+There were multiple iterations of the ``manylinux`` specification, each
 representing the common subset of Linux platforms at a given point in time:
 
 * ``manylinux1`` (:pep:`513`) supports ``x86_64`` and ``i686``
@@ -51,6 +51,11 @@ representing the common subset of Linux platforms at a given point in time:
   and ``s390x``) and updates the base platform to a compatible Linux platform
   from 2014.
 
+``manylinux_x_y`` (:pep:`600`) supersedes all previous PEPs to define a
+future-proof standard. It defines ``x`` and ``y`` as glibc major an minor
+versions supported (e.g. ``manylinux_2_24`` should work on any distro using
+glibc 2.24+). Previous tags are still supported for backward compatibility.
+
 In general, distributions built for older versions of the specification are
 forwards-compatible (meaning that ``manylinux1`` distributions should continue
 to work on modern systems) but not backwards-compatible (meaning that
@@ -59,26 +64,27 @@ existed before 2010).
 
 Package maintainers should attempt to target the most compatible specification
 possible, with the caveat that the provided build environment for
-``manylinux1`` has reached end-of-life, and the build environment for
-``manylinux2010`` will reach end-of-life in November 2020 [#]_, meaning that
+``manylinux1`` and ``manylinux2010`` have reached end-of-life meaning that
 these images will no longer receive security updates.
 
 Manylinux compatibility support
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. Note::
-   The ``manylinux2014`` specification is relatively new and is not yet widely
-   recognised by install tools.
+  * The ``manylinux2014`` specification is relatively new and is not yet widely
+    recognised by install tools.
+  * The ``manylinux_x_y`` specification is relatively new and is not yet widely
+    recognised by install tools.
 
 The following table shows the minimum versions of relevant projects to support
 the various ``manylinux`` standards:
 
-==========  ==============  =================  =================
-Tool        ``manylinux1``  ``manylinux2010``  ``manylinux2014``
-==========  ==============  =================  =================
-pip         ``>=8.1.0``     ``>=19.0``         ``>=19.3``
-auditwheel  ``>=1.0.0``     ``>=2.0.0``        ``>=3.0.0``
-==========  ==============  =================  =================
+==========  ==============  =================  =================  =================
+Tool        ``manylinux1``  ``manylinux2010``  ``manylinux2014``  ``manylinux_x_y``
+==========  ==============  =================  =================  =================
+pip         ``>=8.1.0``     ``>=19.0``         ``>=19.3``         ``>=20.3``
+auditwheel  ``>=1.0.0``     ``>=2.0.0``        ``>=3.0.0``        ``>=3.3.0`` [#]_
+==========  ==============  =================  =================  =================
 
 Platform tags for other \*nix platforms
 ---------------------------------------
@@ -89,4 +95,4 @@ distribution of wheel files to other \*nix platforms. Efforts are currently
 schemes for AIX and for Alpine Linux.
 
 
-.. [#] https://wiki.centos.org/About/Product
+.. [#] Only support for ``manylinux_2_24`` has been added in auditwheel 3.3.0

source/tutorials/packaging-projects.rst

@@ -195,22 +195,23 @@ an escape hatch when absolutely necessary.
     There are many more than the ones mentioned here. See
     :doc:`/guides/distributing-packages-using-setuptools` for more details.
 
-
     If you create a :file:`setup.py` file, this will enable direct interaction
     with :file:`setup.py` (which generally should be avoided), and editable
     installs. This file used to be required, but can be omitted in modern
-    setuptools.
-
-    Anything you set in :file:`setup.cfg` can instead be set via keyword argument to
-    :func:`setup()`; this enables computed values to be used. You will also need
-    :func:`setup()` for setting up extension modules for compilation.
+    setuptools. If you include the file, you must have a call to
+    :func:`setup()` in it:
 
     .. code-block:: python
 
         import setuptools
 
         setuptools.setup()
 
+    Anything you set in :file:`setup.cfg` can instead be set via keyword argument to
+    :func:`setup()`; this enables computed values to be used. You will also need
+    :func:`setup()` for setting up extension modules for compilation.
+
+
 .. tab:: setup.py (dynamic)
 
     :file:`setup.py` is the build script for :ref:`setuptools`. It tells setuptools