PEP 708: Clarifications + Reject Defining the Explicit Configuration (#…

…3060)

Update PEP 708 to clarify a few things

pep-0708.rst

@@ -171,6 +171,11 @@ metadata:
 - It **MUST** be under the control of the repository operators themselves, not
   any individual publisher using that repository.
 
+  - "Repository Operator" can also include anyone who managed the overall
+    namespace for a particular repository, which may be the case in situations
+    like hosted repository services where one entity operates the software but
+    another owns/manages the entire namespace of that repository.
+
 - It **MUST** represent the same "project" as the project at the referenced URL.
 
   - This does not mean that it needs to serve the same files. It is valid for it
@@ -269,6 +274,13 @@ When an installer encounters a project that is using the alternate locations
 metadata it **SHOULD** consider that all repositories named are extending the
 same namespace across multiple repositories.
 
+.. note::
+
+  This alternate locations metadata is project level metadata, not artifact
+  level metadata, which means it doesn't get included as part of the core
+  metadata spec, but rather it is something that each repository will have to
+  provide a configuration option for (if they choose to support it).
+
 
 JSON
 ~~~~
@@ -848,18 +860,24 @@ common for people to use their own registries, but in Python we encourage you to
 do just that.
 
 
-Open Questions
-==============
+Define and Standardize the "Explicit Configuration"
+---------------------------------------------------
+
+This PEP recommends installers to have a mechanism for explicit configuration of
+which repository a particular project comes from, but it does not define what
+that mechanism is. We are purposefully leave that undefined, as it is closely
+tied to the UX of each individual installer and we want to allow each individual
+installer the ability to expose that configuration in whatever way that they see
+fit for their particular use cases.
+
+Further, when the idea of defining that mechanism came up, none of the other
+installers seemed particularly interested in having that mechanism defined for
+them, suggesting that they were happy to treat that as part of their UX.
 
-*  The `original proposal document <https://docs.google.com/document/d/184fQkb6NggVQfYmjTDA7p_U3iWDKk6grc2DigT1X3Es/>`__
-   was targeted more specifically to a change to pip, and went into more
-   specific details as to what we expected from pip. Since dictating UX to
-   installers isn't something that we do in PEPs, I've rewritten those parts to
-   be more generic; however, that means that we lose the information on
-   repository files. Is that fine? Or should we standardize what a repository
-   file looks like so the same file can be given to multiple installers instead
-   of hand waving around the specific mechanism installers would use for
-   explicit configuration?
+Finally, that mechanism, if we did choose to define it, deserves it's own PEP
+rather than baking it as part of the changes to the repository API in this PEP
+and it can be a future PEP if we ultimately decide we do want to go down the
+path of standardization for it.
 
 
 Acknowledgements