forked from python/peps
-
Notifications
You must be signed in to change notification settings - Fork 1
PEP 825: reword ordering to avoid introducing new terms #47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
mgorny
wants to merge
1
commit into
pep-wheel-variants-acceptance
Choose a base branch
from
pep-wheel-variants-stage
base: pep-wheel-variants-acceptance
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -379,17 +379,23 @@ like: | |
| Variant ordering | ||
| ---------------- | ||
|
|
||
| To determine which variant wheel to install when multiple wheels are | ||
| compatible, variants MUST be totally ordered by their variant | ||
| properties. | ||
| To determine which wheel to install when multiple wheels are compatible, | ||
| variant metadata MUST be taken into consideration. This section | ||
| describes the selection based on the assumption that all wheels are | ||
| sorted in the order of priority. Tools that select wheels using | ||
| different algorithms MUST implement them so that they arrive at the same | ||
| result. | ||
|
Comment on lines
+385
to
+387
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I consider that implied, we don't need to say that explicitly: The spec is not the algorithm, but the observed output or behavior. |
||
|
|
||
| For the purpose of ordering, variant properties are grouped into | ||
| features, and features into namespaces. For every namespace, the tool | ||
| MUST obtain an ordered list of compatible features, and for every | ||
| feature, an ordered list of compatible values. The method of obtaining | ||
| these lists will be defined in a subsequent PEP. | ||
|
|
||
| The default ordering MUST be performed equivalent to the following | ||
| The compatible wheels corresponding to a particular combination of | ||
| package name, version and build number MUST be grouped by their variant | ||
| label, and a separate group of non-variant wheels MUST be formed. The | ||
| groups of variant wheels MUST then be ordered according to the following | ||
| algorithm: | ||
|
|
||
| 1. Construct the ordered list of namespaces by copying the value of the | ||
|
|
@@ -422,41 +428,42 @@ algorithm: | |
| After this step, a list of ordered property values is available for | ||
| every feature. This is ``value_order`` in the example. | ||
|
|
||
| 4. For every compatible variant, determine the most preferred value | ||
| corresponding to every feature in that variant. This is done by | ||
| finding among the values present in the variant properties the one | ||
| that has the lowest position in the ordered property value list. | ||
| After this step, a list of features along with their best values | ||
| is available for every variant. This is done in the | ||
| ``Variant.best_value_properties()`` method in the example. | ||
| 4. For every group, determine the most preferred value corresponding to | ||
| every variant feature present. This is done by finding among the | ||
| values present in the variant properties the one that has the lowest | ||
| position in the ordered property value list. After this step, a list | ||
| of features along with their best values is available for every | ||
| variant. This is done in the ``VariantWheel.best_value_properties()`` | ||
| method in the example. | ||
|
|
||
| 5. For every item in the list constructed in the previous step, | ||
| construct a sort key that is a 3-tuple consisting of | ||
| its namespace, feature name and best feature value indices in the | ||
| respective ordered lists. This is done by the ``property_key()`` | ||
| function in the example. | ||
|
|
||
| 6. For every compatible variant, sort the list constructed in step 4 | ||
| using the sort keys constructed in step 5, in ascending order. This | ||
| is done by the ``Variant.sorted_properties()`` method in the example. | ||
| 6. For every group, sort the list constructed in step 4 using the sort | ||
| keys constructed in step 5, in ascending order. This is done by the | ||
| ``VariantWheel.sorted_properties()`` method in the example. | ||
|
|
||
| 7. To order variants, compare their sorted lists from step 6. If the | ||
| sort keys at the first position are different, the variant with the | ||
| 7. To order groups, compare their sorted lists from step 6. If the | ||
| sort keys at the first position are different, the group with the | ||
| lower key is sorted earlier. If they are the same, compare the keys | ||
| at the second position, and so on, until either a tie-breaker is | ||
| found or the list in one of the variants is exhausted. In the latter | ||
| case, the variant with more keys is sorted earlier. As a fallback, | ||
| if both variants have the same number of keys, they are ordered | ||
| lexically by their variant label, ascending. This is done by the | ||
| found or the list in one of the groups is exhausted. In the latter | ||
| case, the group with more keys is sorted earlier. As a fallback, | ||
| if both groups have the same number of keys, they are ordered | ||
| lexically by the variant label, ascending. This is done by the | ||
| ultimate step of the example algorithm, with the comparison function | ||
| being implemented as ``Variant.__lt__()``. | ||
| being implemented as ``VariantWheel.__lt__()``. | ||
|
|
||
| After this process, the variant wheels are sorted from the most | ||
| preferred to the least preferred. The algorithm sorts the null variant | ||
| after all the other variants. The non-variant wheel MUST be ordered | ||
| after the null variant. Multiple wheels with the same variant property | ||
| set (and multiple non-variant wheels) MUST then be ordered according to | ||
| their platform compatibility tags. | ||
| The algorithm sorts the group of null variant wheels last, as they | ||
| feature no variant properties. The group of non-variant wheels MUST be | ||
| placed after all the other groups. | ||
|
|
||
| Within every group, the wheels MUST then be ordered according to their | ||
| platform compatibility tags. After this process, the variant wheels are | ||
| sorted from the most preferred to the least preferred. | ||
|
|
||
| The tools MAY provide options to override the default ordering, for | ||
| example by specifying a preference for specific namespaces, features | ||
|
|
@@ -465,7 +472,8 @@ variants, or to select a particular variant. | |
|
|
||
| Alternatively, the sort algorithm for variant wheels could be described | ||
| using the following pseudocode. For simplicity, this code does not | ||
| account for non-variant wheels or tags. | ||
| account for non-variant wheels or the subsequent ordering by platform | ||
| compatibility tags. | ||
|
|
||
| .. code:: python | ||
|
|
||
|
|
@@ -530,7 +538,7 @@ account for non-variant wheels or tags. | |
| ) | ||
|
|
||
|
|
||
| class Variant: | ||
| class VariantWheel: | ||
| """Example class exposing properties of a variant wheel""" | ||
|
|
||
| label: str | ||
|
|
@@ -571,13 +579,13 @@ account for non-variant wheels or tags. | |
| return self.label < other.label | ||
|
|
||
|
|
||
| # A list of variants to sort. | ||
| variants: list[Variant] = [...] | ||
| # A list of variant wheels to sort. | ||
| variant_wheels: list[VariantWheel] = [...] | ||
|
|
||
|
|
||
| # 7. Order variants by comparing their sorted properties | ||
| # (see Variant.__lt__()) | ||
| variants.sort() | ||
| # 7. Order variant wheels by comparing their sorted properties | ||
| # (see VariantWheel.__lt__()) | ||
| variant_wheels.sort() | ||
|
|
||
|
|
||
| Environment markers | ||
|
|
||
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could be misconstrued as saying that you have to support variants to be correct, and can't ignore variants (which we otherwise say is fine, if you're fine with not getting the best package). I think what we want to say is that you need to consider variant metadata if you want to determine the priority order between a set of wheel using variants. This way we are clear about priorities/ordering, but leave it to the tools what to do with that.
We could also approach this in a different way, and say: "This specification defines an ordering between different variant wheels based on the variant label." The implications are clear, and it also ensure that e.g. index-specific behaviors are left to the tools.