PEP 9998: building (draft; do not merge)

[mgorny]

Here's an early draft, mostly as context to #40.

---

📚 Documentation preview 📚: https://wheelnext-peps--44.org.readthedocs.build/

[read-the-docs-community]

Documentation build overview

📚 wheelnext-peps | 🛠️ Build #34807712 | 📁 Comparing df2b8e4 against latest (344e589)

  🔍 Preview build  

52 files changed · + 7 added · ± 45 modified

+ Added

• pep-0845/index.html
• pep-0846/index.html
• pep-0847/index.html
• pep-9998/index.html
• pep-9999/index.html
• pep-0825/appendix-metadata-consistency/index.html
• pep-9999/appendix-variant-json-schema/index.html

± Modified

• index.html
• numerical/index.html
• pep-0000/index.html
• pep-0426/index.html
• pep-0501/index.html
• pep-0534/index.html
• pep-0545/index.html
• pep-0585/index.html
• pep-0604/index.html
• pep-0654/index.html
• and 35 more...

[rgommers]

This looks pretty good to me, thanks @mgorny! I only have a handful of comments at the moment.

[rgommers]

The word "seed" here and in the next section isn't too helpful. It seems to imply that changes may occur, it's only a starting point (a la "random seed"). That isn't the case - the metadata in pyproject.toml and in variants.json should actually be 100% consistent. And as for PEP 621, if both exist, I'd expect the pyproject.toml version to be authoritative.

[mgorny]

I'm not opposed to replacing or removing "seed", but there are some differences:

1. variants will only include the selected variant.
2. providers.{namespace}.static-properties may be filled from a plugin.
3. default-priorities.feature.{namespace} may be filled from a plugin.

[rgommers]

This example works well (nit: the x8664 spelling looks off to my eyes, can it be replaced with x86-64?). It may be useful to add an example invocation maybe?

$ pip install . -Cvariant-label=x86-64_v3
...
built xxx.whl

[mgorny]

Uh, actually it was supposed to be x8664v4_mkl, with the (non-normative) assumption that we're using _ to split different properties here. I'm fine with changing it but then we should probably change the labels in 825 too, to keep the variant labels consistent across the examples.

[rgommers]

This Rationale is well-written and very useful. I think it's easier to understand the specification after reading this section. I'd put Rationale above Specification for that reason (which is where it normally goes anyway). Coming to a terse Specification first, the reader will likely lack context.

Alternatively, at least this first paragraph could go above it (in Motivation maybe?), because it sets the context well. The rest of this Rationale is more about explaining individual design decisions, but this first paragraph is not.

[mgorny]

Oh, I actually forgot that Rationale normally comes prior to Specification. Do you think it's better to move it wholesome, or split as you suggested in the second alternative, and keep Rationale after Specification?

[rgommers]

I just remembered that I had made a diagram early on in wheelnext/pep_817_wheel_variants#9. Here's the latest version:

Needs some tweaks to align with the final version of this PEP, but we may want to consider including it - a lot easier to grasp than lots of text and numbered lists of steps.

EDIT: or better, include into the reworked PEP 817 as an Informational PEP, since it looks like we're going that way.

[rgommers]

This probably is still in flux at the moment, but I had a look. Overall looks good, and all of the main decisions still make sense to me. The main comment I have right now is that default-priorities.feature is still used in some places.