Merge remote-tracking branch 'upstream/main' into trusted-publishing-guide

Author: chrysle

.github/workflows/test.yml

@@ -1,6 +1,7 @@
 name: Test
 
 on:
+  merge_group:
   push:
   pull_request:
   schedule:
@@ -27,7 +28,7 @@ jobs:
       - name: Set up Python
         uses: actions/setup-python@v4
         with:
-          python-version: 3.9
+          python-version: "3.11"
           cache: 'pip'
           cache-dependency-path: 'requirements.txt'
 
@@ -38,3 +39,21 @@ jobs:
       - name: Nox ${{ matrix.noxenv }}
         run: |
           python -m nox -s ${{ matrix.noxenv }}
+
+
+  check:
+    # This job does nothing and is only used for the branch protection
+    # or multi-stage CI jobs, like making sure that all tests pass before
+    # a publishing job is started.
+    if: always()
+
+    needs:
+    - build
+
+    runs-on: ubuntu-latest
+
+    steps:
+    - name: Decide whether the needed jobs succeeded or failed
+      uses: re-actors/alls-green@release/v1
+      with:
+        jobs: ${{ toJSON(needs) }}

source/contribute.rst

@@ -63,7 +63,7 @@ document <discussions/install-requires-vs-requirements>`.
 Specifications
 --------------
 
-Specifications are reference documention focused on comprehensively documenting
+Specifications are reference documentation focused on comprehensively documenting
 an agreed-upon interface for interoperability between packaging tools.
 :doc:`example specification-style document <specifications/core-metadata>`.
 
@@ -131,9 +131,9 @@ need:
 
       python -m pip install --user nox
 
-2. Python 3.8. Our build scripts are usually tested with Python 3.8 only.
+2. Python 3.11. Our build scripts are usually tested with Python 3.11 only.
    See the :doc:`Hitchhiker's Guide to Python installation instructions <python-guide:starting/installation>`
-   to install Python 3.8 on your operating system.
+   to install Python 3.11 on your operating system.
 
 To build the guide, run the following shell command in the project's root folder:
 

source/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows.rst

@@ -161,9 +161,9 @@ the contents of the ``dist/`` folder into PyPI unconditionally.
 Signing the distribution packages
 =================================
 
-This additional job signs the distribution packages with the
-`sigstore/gh-action-sigstore-python GitHub Action`_ and then uploads
-them to GitHub Release.
+This additional job signs the distribution packages with `Sigstore`_,
+using the `sigstore/gh-action-sigstore-python GitHub Action`_,
+and then uploads them to GitHub Release.
 
 .. literalinclude:: github-actions-ci-cd-sample/publish-to-test-pypi.yml
    :language: yaml
@@ -220,6 +220,7 @@ sure that your release pipeline remains healthy!
    https://github.com/actions/download-artifact
 .. _`upload-artifact`:
    https://github.com/actions/upload-artifact
+.. _Sigstore: https://www.sigstore.dev/
 .. _`sigstore/gh-action-sigstore-python GitHub Action`:
    https://github.com/marketplace/actions/gh-action-sigstore-python
 .. _Secrets:

source/key_projects.rst

@@ -184,7 +184,7 @@ check for CVEs in `Pipfile` using `safety <https://pyup.io/safety>`_.
 
 Pipenv aims to help users manage environments, dependencies, and
 imported packages on the command line. It also works well on Windows
-(which other tools often underserve), makes and checkes file hashes,
+(which other tools often underserve), makes and checks file hashes,
 to ensure compliance with hash-locked dependency specifiers, and eases
 uninstallation of packages and dependencies.
 
@@ -558,7 +558,6 @@ resolution by locally caching metadata about dependencies.
 pypiserver
 ==========
 
-`Docs <https://github.com/pypiserver/pypiserver/blob/master/README.rst>`__ |
 `GitHub <https://github.com/pypiserver/pypiserver>`__ |
 `PyPI <https://pypi.org/project/pypiserver/>`__
 

source/news.rst

@@ -118,7 +118,7 @@ March 2018
 - Updated "installing scientific packages". (:pr:`455`)
 - Added :file:`long_description_content_type` to follow PEP 556. (:pr:`457`)
 - Clarified a long description classifier on pypi.org. (:pr:`456`)
-- Updated Core Metadata spec to follw PEP 556. (:pr:`412`)
+- Updated Core Metadata spec to follow PEP 556. (:pr:`412`)
 
 February 2018
 -------------
@@ -214,7 +214,7 @@ April 2017
 - Added documentation explaining prominently how to install ``pip`` in ``/usr/local``. (:pr:`230`)
 - Updated development mode documentation to mention that order of local packages matters. (:pr:`208`)
 - Convert readthedocs link for their ``.org`` -> ``.io`` migration for hosted projects (:pr:`239`)
-- Swaped order of :file:`setup.py` arguments for the upload command, as order
+- Swapped order of :file:`setup.py` arguments for the upload command, as order
   is significant. (:pr:`260`)
 - Explained how to install from unsupported sources using a helper application. (:pr:`289`)
 

source/specifications/recording-installed-packages.rst

@@ -59,14 +59,14 @@ encouraged to start normalizing those fields.
 
 .. note::
 
-    The ``.dist-info`` directory's name is formatted to unambigiously represent
+    The ``.dist-info`` directory's name is formatted to unambiguously represent
     a distribution as a filesystem path. Tools presenting a distribution name
     to a user should avoid using the normalized name, and instead present the
     specified name (when needed prior to resolution to an installed package),
     or read the respective fields in Core Metadata, since values listed there
     are unescaped and accurately reflect the distribution. Libraries should
     provide API for such tools to consume, so tools can have access to the
-    unnormalized name when displaying distrubution information.
+    unnormalized name when displaying distribution information.
 
 This ``.dist-info`` directory may contain the following files, described in
 detail below:
@@ -234,7 +234,7 @@ packages into a Python environment to ensure that other tools are not used to
 uninstall or otherwise modify that installed package, as doing so may cause
 compatibility problems with the wider environment.
 
-To achieve this, affected tools should take the folllowing steps:
+To achieve this, affected tools should take the following steps:
 
 * Rename or remove the ``RECORD`` file to prevent changes via other tools (e.g.
   appending a suffix to create a non-standard ``RECORD.tool`` file if the tool
@@ -251,4 +251,4 @@ ensuring both locations appear on the default Python import path).
 
 In some circumstances, it may be desirable to block even installation of
 additional packages via Python-specific tools. For these cases refer to
-:ref:`externally-managed-environments`
+:ref:`externally-managed-environments`

source/specifications/simple-repository-api.rst

@@ -5,9 +5,16 @@
 Simple repository API
 =====================
 
-The current interface for querying available package versions and
-retrieving packages from an index server is defined in :pep:`503`,
-with the addition of "yank" support (allowing a kind of file deletion)
-in :pep:`592`, specifying the interface version provided
-by an index server in :pep:`629`, and providing package metadata
-independently from a package in :pep:`658`.
+The interface for querying available package versions and
+retrieving packages from an index server comes in two forms:
+HTML and JSON.
+
+The HTML format is defined in :pep:`503`, with the addition of "yank"
+support (allowing a kind of file deletion) in :pep:`592`, specifying
+the interface version provided by an index server in :pep:`629`, and
+providing package metadata independently from a package in
+:pep:`658` and revised in :pep:`714`.
+
+The JSON format is defined in :pep:`691`, with additional fields
+added in :pep:`700`, and revisions around providing package metadata
+independently from a package in :pep:`714`.

source/specifications/virtual-environments.rst

@@ -19,7 +19,7 @@ Runtime detection of virtual environments
 
 At runtime, virtual environments can be identified by virtue of ``sys.prefix``
 (the filesystem location of the running interpreter) having a different value
-from ``sys.base_prefix`` (the default filesytem location of the standard library
+from ``sys.base_prefix`` (the default filesystem location of the standard library
 directories).
 
 :ref:`venv-explanation` in the Python standard library documentation for the