PEP 817: add The Design Space part of the PEP, improve other sections - #87
Conversation
Documentation build overview
52 files changed ·
|
Also a minor wording improvement to one other section.
| verifying the validity of variant properties and embedding static | ||
| properties via plugins at build time. | ||
|
|
||
| - UX, maintainability, security and governance: the introduction |
There was a problem hiding this comment.
Here looks like we are trying to put a lot of concepts in 1 PEP. Should we separate this in 2 ?
-
PEP 4 — UX, maintainability, security. What installers do: the introduction strategy, opt-in mechanics, when a provider runs, what the user sees, how trust is expressed in tooling. A spec, reviewable by installer maintainers, mostly tractable.
-
PEP 5 — the trusted-provider repository and its governance. Who curates, on what criteria, with what appeal process, funded and staffed by whom. An ongoing institution, reviewable by PyPA/packaging-council, and by far the slowest-moving piece.
There was a problem hiding this comment.
I'd much prefer to not touch this now, because we've consistently said that we have four PEPs, and this set of topics goes quite well together. We haven't started working on this PEP yet; if it gets too large we can change it later, but I don't want to do that now.
"Platform tag" is one of the three tags the wheel filename carries, alongside the Python tag and the ABI tag; "platform compatibility tags" is the collective name, and the name of the specification. Using the bare plural understated the claim being made - none of the three can express these properties, not just the third - and pointed readers at the wrong tag for the ABI example.
Focus on the use cases where this functionality is essential, and mention the "runs the least code" as a secondary benefit. The providers have a good security story, so there's no need to have the static file option if that were the only reason; instead it's a hard necessity for some use cases like building containers.
|
The changes I just pushed should address all open comments, please take another look. |
8628e2a to
e10c3c0
Compare
|
Addressed Michal's comments, ready again. |
|
This had three reviewers and two approvals, with @atalman's comments also addressed (and not controversial I think, just regular improvements). So I plan to merge this later tonight or tomorrow morning, unless anyone needs more time. |
|
Upstream PR for the update to 817: python#5149 |
4 participants
The largest addition is a side-by-side comparison of five design options, which are the ones we've considered and those that have been brought up in the various discussions on DPO. It's deliberately side-by-side, so reviewers can understand how we arrived at the current design.
Note that in a call a while back, I showed a similar table to the one added now, but with more decision criteria and explicit scoring (good, medium, bad with emoji's); I decided against that because any scoring as well as the choices of more detailed criteria can all be argued with, while the version in this PR is as objective as possible.
Other sections that are updated:
Sections added or touched in the design overview:
The Motivation and Prior Art sections were not touched significantly.
With these updates, I think the PEP is ready to be used as an Informational umbrella PEP.