From d873459b7f31db6518e648fcf63c43f399a217ca Mon Sep 17 00:00:00 2001 From: Donald Stufft Date: Sat, 18 Mar 2023 01:35:34 -0400 Subject: [PATCH] PEP 708: Clarifications + Reject Defining the Explicit Configuration (#3060) Update PEP 708 to clarify a few things --- pep-0708.rst | 40 +++++++++++++++++++++++++++++----------- 1 file changed, 29 insertions(+), 11 deletions(-) diff --git a/pep-0708.rst b/pep-0708.rst index 986d28e5600..75e1db10675 100644 --- a/pep-0708.rst +++ b/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 `__ - 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