PEP 766: explicit priority choices among multiple indexes

Apply suggestions from code review

Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>

.github/CODEOWNERS

@@ -642,6 +642,7 @@ peps/pep-0761.rst  @sethmlarson @hugovk
 peps/pep-0762.rst  @pablogsal @ambv @lysnikolaou @emilyemorehouse
 peps/pep-0763.rst  @dstufft
 peps/pep-0765.rst  @iritkatriel @ncoghlan
+peps/pep-0766.rst  @warsaw
 # ...
 peps/pep-0777.rst  @warsaw
 # ...

peps/pep-9999.rst → peps/pep-0766.rst

@@ -1,34 +1,34 @@
-PEP: 9999
+PEP: 766
 Title: Explicit Priority Choices Among Multiple Indexes
 Author: Michael Sarahan, msarahan@gmail.com
 Sponsor: Barry Warsaw, barry@python.org
-PEP-Delegate: <PEP delegate’s real name>
-Discussions-To: <REQUIRED: URL of current canonical discussion thread>
+PEP-Delegate: Paul Moore <p.f.moore@gmail.com>
+Discussions-To: https://discuss.python.org/t/pep-for-handling-multiple-indexes-index-priority/71589
 Status: Draft
 Type: Informational
 Topic: Packaging
 Requires: 777
-Created: 05-Nov-2024
-Post-History: <REQUIRED: dates, in dd-mmm-yyyy format, and corresponding links to PEP discussion threads>
+Created: 18-Nov-2024
+Post-History: `18-Nov-2024 <https://discuss.python.org/t/pep-for-handling-multiple-indexes-index-priority/71589>`__,
 
 Abstract
 ========
 
-Package resolution is a key part of the Python user experience as the 
-means of extending Python's core functionality. The experience of package 
-resolution is mostly taken for granted until someone encounters a 
-situation where the package installer does something they don't expect. 
+Package resolution is a key part of the Python user experience as the
+means of extending Python's core functionality. The experience of package
+resolution is mostly taken for granted until someone encounters a
+situation where the package installer does something they don't expect.
 The installer behavior with multiple indexes has been `a common source of unexpected behavior <https://github.com/pypa/pip/issues/8606>`__.
-Through its ubiquity, pip has long defined the standard expected behavior 
-across other tools in the ecosystem, but Python installers are diverging 
-with respect to how they handle multiple indexes. At the core of this 
-divergence is whether index contents are combined before resolving distributions, 
+Through its ubiquity, pip has long defined the standard expected behavior
+across other tools in the ecosystem, but Python installers are diverging
+with respect to how they handle multiple indexes. At the core of this
+divergence is whether index contents are combined before resolving distributions,
 or each index is handled individually in order. Pip merges all indexes
 before matching distributions, while uv matches distributions on one index
 before moving on to the next. Each approach has advantages and disadvantages.
-This PEP aims to describe each of these behaviors, which are referred to 
+This PEP aims to describe each of these behaviors, which are referred to
 as “version priority” and “index priority” respectively, so that community
-discussions and troubleshooting can share a common vocabulary, and so that tools can 
+discussions and troubleshooting can share a common vocabulary, and so that tools can
 implement predictable behavior based on these descriptions.
 
 Motivation
@@ -46,7 +46,7 @@ Goals
 - Provide guidelines for how ecosystem tools should implement index
   priority if they would like, and suggest reasons why they might want
   to do so
-- Augment `PEP 708 <https://peps.python.org/pep-0708/>`__ as a more 
+- Augment `PEP 708 <https://peps.python.org/pep-0708/>`__ as a more
   user-configurable system for expressing different levels of trust
   among configured indexes
 
@@ -67,11 +67,11 @@ Rationale
 =========
 
 This PEP describes two modes of installer behavior when using multiple
-sources in the hopes that the user experience and expectations across 
-tools can be more explicit and more predictable. Pip has long defined 
-the de-facto standard installer behavior in the ecosystem, but new tools 
+sources in the hopes that the user experience and expectations across
+tools can be more explicit and more predictable. Pip has long defined
+the de-facto standard installer behavior in the ecosystem, but new tools
 have been implementing new approaches in response to both security concerns
-and desire to prioritize one index over another. Uv and PDM have each 
+and desire to prioritize one index over another. Uv and PDM have each
 added support for some notion of index priority.
 
 Index priority is `the default behavior in
@@ -112,8 +112,8 @@ different contents than other indexes, such as builds for special
 hardware, and this version priority behavior can lead to undesirable,
 unexpected outcomes, and this is when users generally look for some kind
 of index priority. Additionally, when there is a difference in trust among
-indexes, version priority does not provide a way to prefer more trusted 
-indexes over less trusted indexes. This has been the subject of dependency 
+indexes, version priority does not provide a way to prefer more trusted
+indexes over less trusted indexes. This has been the subject of dependency
 confusion attacks, and :pep:`708` was
 proposed as a way of hard-coding a notion of trusted external indexes into
 the index.
@@ -160,15 +160,15 @@ packages are compared.
 “Index priority”
 ----------------
 
-In index priority, the resolver finds candidates for each index, one at a time. 
+In index priority, the resolver finds candidates for each index, one at a time.
 The resolver proceeds to subsequent indexes only if the current
 package request has no viable candidates. Index priority does not combine
-indexes into one global, flat namespace. Because indexes are searched in order, 
+indexes into one global, flat namespace. Because indexes are searched in order,
 the package from an earlier index  will be preferred over a package from a later index, regardless of whether
 the later index had a better match. Uv’s calls this "first-match"
 behavior, and the version priority behavior "best-match". The criteria and process for
 evaluating “best match” is the same for both index priority and version
-priority. It is only the treatment of multiple indexes that differs: 
+priority. It is only the treatment of multiple indexes that differs:
 all together for version priority, and individually for index priority.
 
 The index (or “source” in PDM terms) priority is