PEP 9998: building (draft; do not merge)#44
Conversation
mgorny
force-pushed
the
pep-building
branch
3 times, most recently
from
2fed7a0 to
96c81fc
Compare
| For consistency, it is RECOMMENDED that build backends implement the | ||
| following interface for building variant wheels: | ||
|
|
||
| - variant metadata seed is stored in ``pyproject.toml`` file, as |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I'm not opposed to replacing or removing "seed", but there are some differences:
variantswill only include the selected variant.providers.{namespace}.static-propertiesmay be filled from a plugin.default-priorities.feature.{namespace}may be filled from a plugin.
| [variant.variants.x8664_v4_mkl] | ||
| blas_lapack.library = ["mkl"] | ||
| x86_64.level = ["v4"] | ||
|
|
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
| consistent user experience, but are by no means mandatory. The standard | ||
| ``pyproject.toml`` file is used to avoid spreading the project | ||
| configuration across multiple files, and the same schema as for variant | ||
| metadata is used. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
Signed-off-by: Michał Górny <mgorny@quansight.com>
Signed-off-by: Michał Górny <mgorny@quansight.com>
Signed-off-by: Michał Górny <mgorny@quansight.com>
Signed-off-by: Michał Górny <mgorny@quansight.com>
Signed-off-by: Michał Górny <mgorny@quansight.com>
Signed-off-by: Michał Górny <mgorny@quansight.com>
Signed-off-by: Michał Górny <mgorny@quansight.com>
Signed-off-by: Michał Górny <mgorny@quansight.com>
Signed-off-by: Michał Górny <mgorny@quansight.com>
Signed-off-by: Michał Górny <mgorny@quansight.com>
Signed-off-by: Michał Górny <mgorny@quansight.com>
Signed-off-by: Michał Górny <mgorny@quansight.com>
Signed-off-by: Michał Górny <mgorny@quansight.com>
2 participants
Here's an early draft, mostly as context to #40.
📚 Documentation preview 📚: https://wheelnext-peps--44.org.readthedocs.build/