Skip to content

Conversation

@JP-Ellis
Copy link

@JP-Ellis JP-Ellis commented Oct 7, 2025

According to the environment markers, most markers are strings, with only a small subset being use to handle versions. As such, this PR changes the behaviour to use version comparison only on those keys which are dealing with versions.

Note that the choice of only doing version comparison on keys which are defined as being versions results in one failure for a custom key:

    def test_prefers_pep440(self):
>       assert Marker('"2.7.9" < "foo"').evaluate(dict(foo="2.7.10"))
E       assert False
E        +  where False = evaluate({'foo': '2.7.10'})
E        +    where evaluate = <Marker('"2.7.9" < "foo"')>.evaluate
E        +      where <Marker('"2.7.9" < "foo"')> = Marker('"2.7.9" < "foo"')
E        +    and   {'foo': '2.7.10'} = dict(foo='2.7.10')

From my reading of the specification, it is unclear whether the use of version comparison in this case is meant to be supported or not.

I can see a few ways of moving forward

  1. If version comparisons are only meant to be used with the defined set of keys, then this PR is ready to go, requiring only that the one test be changed to expect failure.

  2. If version comparison should be the default, and only some keys are exempted from the version comparison, then we can invert the logic in _eval_op from an if key in MARKERS_REQUIRING_VERSION: to an if key in MARKERS_REQUIRING_STRING_COMPARISON. If this is the case, then we would need to define what those keys are.

  3. An intermediate approach would be to inspect the operator and, for example, using version comparison for <, <=, >=, >, ~= and ===, and string comparison for == and !=. I don't like this approach as it muddies the logic, and I think it would be better to be explicit about which keys are to be treated as versions.

Resolves: #938
Replaces: #932 (this is a different approach)

Copy link
Contributor

@Liam-DeVoe Liam-DeVoe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Replaces: #932 (this is a different approach)

I don't think this supersedes #932, because it's still possible to hit InvalidVersion with manual use of SpecifierSet (eg the example in #767). FWIW, the issue in this pull would actually be fixed by #932, though I think the explicit specification of markers which require a version here is good to have regardless.

@henryiii
Copy link
Contributor

henryiii commented Dec 2, 2025

I think the spec needs to change. It states the type depends on the operator used, not on that table (not sure why that table is there, then!), and == is one of the version types. I've proposed an spec update in https://discuss.python.org/t/100287 to allow this to move forward (with platform_release added to the "version-like" set for now, to avoid any real-world effect).

@henryiii
Copy link
Contributor

henryiii commented Dec 8, 2025

I've updated this to follow the spec change update in pypa/packaging.python.org#1971.

@henryiii henryiii force-pushed the fix/only-parse-versions-on-certain-keys branch from 7bc058b to 8375d3a Compare December 29, 2025 17:17
JP-Ellis and others added 4 commits December 29, 2025 18:42
According to the [environment
markers](https://packaging.python.org/en/latest/specifications/dependency-specifiers/#environment-markers),
most markers are strings, with only a small subset being use to handle
versions.

This commit ensures that only those keys which _are_ versions get
compared as versions, and all other keys are compared as string
literals.

Signed-off-by: JP-Ellis <josh@jpellis.me>
Signed-off-by: Henry Schreiner <henryfs@princeton.edu>
Comparisons relying on order are always False.

Signed-off-by: Henry Schreiner <henryfs@princeton.edu>
@henryiii henryiii force-pushed the fix/only-parse-versions-on-certain-keys branch from 96bc364 to 5194f57 Compare December 29, 2025 23:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Invalid version error with evaluating markers

3 participants