Repository navigation
Conversation
Co-authored-by: rgommers <ralf.gommers@gmail.com>
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: - Abstract - Overview of Standards Track PEPs - Backwards Compatibility - Security Implications - Change History - Adoption and Rollout (new) Sections added or touched in the design overview: - Depending on a variant-enabled package (new; this question has come up very regularly) - Package ABI matching (needed a tweak) The Motivation and Prior Art sections were not touched significantly.
Documentation build overview
24 files changed ·
|
warsaw
left a comment
There was a problem hiding this comment.
I have to be honest, both the PEP and the diff are pretty big. I have a bunch of comments and suggestions, but I stalled out several times.
I'm not sure what to suggest, other than try to be more concise in the purpose of this PEP, with a keen eye toward not repeating specifications that will end up in other PEPs for which this one is an umbrella. Other than that, once you resolve my comments, ping me and I'll rubber stamp merge it.
| which form an installer resolves to, and that whatever convention is | ||
| chosen holds for every project using the mechanism. How that would be | ||
| agreed between projects and kept consistent across installers is | ||
| unclear, and the name carries meaning that nothing in the metadata |
There was a problem hiding this comment.
I think that's a great point to lean on. Not that metadata couldn't be added to reflect the differences expressed in the package name, but that would require some standardization (probably a PEP). And without that, once the artifact is gone or is inaccessible, then the distinction is lost. You can get at a package's metadata through importlib.metadata but you usually cannot easily get the artifact once it's installed.
There was a problem hiding this comment.
Great points, expanded this a bit to explain those two things.
| providers. It answers requirements that detection cannot, whatever one's | ||
| view of running code at install time. Installing for a machine other | ||
| than the one running the installer - building a container image for | ||
| other hardware, populating a wheelhouse, reproducing an environment in |
There was a problem hiding this comment.
Does the PEP need to define "wheelhouse"? Is that a term you think readers of the PEP will be familiar with?
There was a problem hiding this comment.
Interesting: I thought it was commonly used, and it is in subsets of the community, but the term appears only once in the Packaging Guide, in an example directory name. So, easier to replace this term with something else, I don't think this is a good place to define terminology that isn't already part of standard packaging vocabulary.
There was a problem hiding this comment.
Replaced with "assembling a set of wheels to install elsewhere".
| most contested aspect of the design, and the mechanisms themselves | ||
| belong to the PEPs listed in `Scope and Standards Track PEPs`_. | ||
|
|
||
| Both extremes fail. An installer automatically running whatever provider |
There was a problem hiding this comment.
This paragraph is a bit convoluted and difficult to parse. Can you simplify or rewrite?
There was a problem hiding this comment.
You're right, rewritten
Co-authored-by: Barry Warsaw <barry@python.org>
Also a few very minor grammatical fixes.
@warsaw thank you for the detailed review! I accepted all your suggestions, and the four that required some thought I left open (all accepted in line with your suggestions). As for "be more concise", that's hard, since the scope is so large. We decided not to touch Motivation or Prior Art from the last round, since those sections seemed fine and didn't yield complaints in previous review - but to shorten, that's probably the place to cut down. The new "The Design Space" section is critical, and summarizes O(1,000) DPO posts, it's as concise as we could manage. And "The wheel variants design" seems needed too, there isn't too much to cut there, and we aimed to do it by worked example to avoid overlap with other PEPs. And there are no specifications at all here, only the 10,000 ft overview. It's probably possible to shrink it a bit, but not a whole lot - I don't think that attempting to further shrink it would be time well-spent. Please take another look. |
This is a large update to the first PEP on Wheel Variants, turning it from an all-in-one Standards Track PEP to an Informational PEP that will serve as the umbrella for the various Standards Track PEPs.
The Specification section has been removed, as that doesn't fit in an Informational PEP.
The Design overview section has been updated, to bring it in line with PEP 825 and current design of the next PEPs.
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.
Other sections that are updated:
The Motivation and Prior Art sections were not touched significantly.
PEP 123: Summary of changes)