fix: restore previous behavior on platform_release #1007
Conversation
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
This walks back the behavior change for
platform_release; in 25.0, it was basically unusable, as without short circuiting, it would throw aInvalidVersionerror when it was not a version (which it is not on some platforms), and you can't stop it from happening. This was fixed in #954 by handling legacy versions as never being "contained", so now any comparisons always return False. Soplatform_release >= '6'will always return False ifplatform_releaseis not a valid Version; the spec states it should fall back to python string comparison. Since this changes to a non-spec compliant behavior, this PR reverts this so it remains unusable.The only field where comparisons other than
==and!=make sense isplatform_release, so I think handling it there only is likely fine.This is a proposal only; I'm also okay with always returning False (current behavior) or updating to match the spec (#889) or fixing the spec (https://discuss.python.org/t/100287).
I believe old versions of packing (with LegacyVersion) had this always False behavior, so that might be a vote in favor of the current version (not this PR). I think that's my current preference.