Repository navigation
馃悰 fix(spec): treat unparsable version specifiers as literal paths - #157
Merged
Merged
Conversation
A version specifier whose version SimpleVersion cannot read, such as `>=3.x`, `>=3.10.post1` or the missing-comma typo `>=3.12 <4`, made get_interpreter and iter_interpreters fail with a bare AssertionError on the first interpreter they checked, so later keys in a list were never tried. SimpleSpecifierSet never raises: it stores an unparsable version as None and drops items without an operator. The literal-path fallback in _parse_specifier therefore never ran, and the None reached the type-narrowing assert in PythonInfo._satisfies_version_specifier. Under -O the assert is gone and the same specs quietly match nothing, and some of them raise AttributeError on a prerelease interpreter. _parse_specifier now falls back to a literal path when an item has no parsed version or no item is left, the same way tox-dev#147 handles malformed version specs. That also stops a spec like `<,4` from matching every interpreter. The assert becomes a no-match check, as in SimpleSpecifier.contains, so a PythonSpec built by hand with such a specifier set no longer crashes either.
SimpleSpecifierSet drops items it cannot parse, so ">=3.12,foo" and ">=3.12, 4" were read as ">=3.12". Fall back to a literal path unless every comma-separated item parsed, which also covers "<,4".
gaborbernat
changed the title
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
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.
get_interpreter([">=3.12 <4", sys.executable])crashed with a bareAssertionErrorinstead of moving on to the next key. 馃悰 Any version specifier whose version python-discovery can't read hit this assert: a missing comma (>=3.12 <4),>=3.x, or forms PEP 440 allows but this parser doesn't, such as>=3.10.post1. Users reach it throughvirtualenv -por tox'sbase_python. Underpython -Othe assert disappears, and the same specs match nothing or raiseAttributeErroron a pre-release interpreter.The specifier set never raises on bad input. It keeps an item with an unreadable version and silently drops an item without an operator. Spec parsing now accepts a specifier only when every comma-separated item parsed into a usable version, and otherwise treats the string as a literal executable path, the same fallback #147 gave
python.. That rule also covers<,4, which used to parse to an empty set and match every interpreter, and>=3.12,fooor>=3.12, 4, which used to lose their second item and act as>=3.12. APythonSpecbuilt by hand can still carry an unreadable version, so the version check returns no match for it instead of asserting.The explanation page now lists the version forms a specifier understands and what happens to anything else.