Return `False` instead of raising for `.contains` with invalid version by Liam-DeVoe · Pull Request #932 · pypa/packaging

Liam-DeVoe · 2025-09-09T06:13:11Z

Closes #767.

notatallshaw · 2025-09-13T19:18:32Z

I'm supportive of this PR, I believe it makes packaging closer to PEP 440 compliant, as invalid versions are expressible via arbitrary equality.

You've added tests for Specifier.contains, SpecifierSet.contains, and SpecifierSet.filter, but you are missing tests for Specifier.filter which should be the same ones you added to TestSpecifierSet.test_specifier_filter but for TestSpecifier.test_specifier_filter.

Liam-DeVoe · 2025-10-04T19:27:37Z

Any movement on this and/or #931? I think these are relatively straightforward changes; and if you'd like to see a different approach instead then I'm happy to do so. I'd love to contribute more to packaging and so I've tried to ease myself in with these contributions, but it's hard to motivate myself to contribute more if PRs sit for this long!

notatallshaw · 2025-10-11T16:09:05Z

It occurs to me that his will likely need a follow up PR where these method handle arbitrary equality, I've wrote up an issue #943

notatallshaw · 2025-10-23T23:19:01Z

Hi @Liam-DeVoe I just recently became a packaging maintainer and I am willing to review and accept this. Unfortunately though I just merged another PR that has caused this PR to have conflicts, if you are okay fixing those conflicts I will review afterward.

Liam-DeVoe · 2025-10-23T23:20:20Z

Congrats! Yes of course, happy to!

…rsion

Liam-DeVoe · 2025-10-23T23:32:38Z

(that CI error is a real mypy warning that should have been an error if I had written better tests - I'll investigate and add a covering test)

Liam-DeVoe · 2025-10-24T00:15:12Z

I'm actually confused as to why #767 says that ===foobar should return False for foobar. On my reading of PEP 440, it should match:

An example would be ===foobar which would match a version of foobar.

I think this is what you were pointing out as well in #943 (comment). I can make this PR return False, so that at least it's not erroring, and then I'm guessing you're already planning a followup to properly handle arbitrary equality and return True instead.

notatallshaw · 2025-10-24T00:18:57Z

@Liam-DeVoe I agree, it's up to you, you can either fix it or I will make a follow up PR, once I am done with the pip 25.3 release, that fixes it.

Liam-DeVoe · 2025-10-24T00:49:05Z

I don't think I'll have immediate time to dig into this in the next few days, so I would say you should go for it.

notatallshaw · 2025-10-25T21:17:02Z

Thanks @Liam-DeVoe for your contribution to packaging.

Liam-DeVoe · 2025-10-25T21:33:05Z

Thank you Damian! I'm hopeful I can continue to contribute where it makes sense.

notatallshaw · 2025-11-01T00:01:05Z

@Liam-DeVoe I've found an interesting edge case adding support for arbitrary equality of arbitrary strings:

SpecifierSet("===foobar,!=1.0").contains("foobar")

Should that be True? And if that's true shouldn't also the following be True:

Specifier("!=1.0").contains("foobar")

I'm tempted to say yes for both and special case != here and not filter invalid versions when there are only != operators.

notatallshaw · 2025-11-01T01:43:28Z

I've made #954 that change the behavior you implemented here, just for empty specifiers and not equal to specifiers.

Liam-DeVoe · 2025-11-01T22:21:21Z

I'm almost tempted to propose that arbitrary equality clauses should not be allowed to appear in the same specifier set as any other clause (ie it must appear alone). === matches exactly one string and one string only, so given a specifier set s with an arbitrary equality clause that matches v, adding another clause c can only either (1) cause s to continue to match v, or (2) cause s to match nothing.

But if ruling out the combination of arbitrary equality clauses with other clauses is not an option, then:

I don't think it's sane to have assert Specifier("!=1.0").contains("foobar"). This might lead to accidentally accepting invalid versions. The way I think of specifier set and arbitrary equality is that SpecifierSet starts with the universe of valid versions. Each non-arbitrary-equality clause added to the specifier set restricts the universe of versions. Adding an arbitrary equality clause has unique semantics, in that it widens the universe of versions to include exactly that version, regardless of what any other clause says.

I know this breaks this very nice invariant:

For any version v and specifiers A and B, if v is not satisfied by A, then v must also not be satisfied by A and B.

But I don't think it's too bad to repair. I would state the following two invariants:

For any valid version v and specifiers A and B, if v is not satisfied by A, then v must also not be satisfied by A and B.

For any invalid version v and specifiers A and B, if v is satisfied by A, then v must also be satisfied by A and B.

Though this second invariant needs some work, e.g. what happens when a specifier set includes two different arbitrary equality clauses. I think disallowing multiple arbitrary equality clauses in the same specifier set would be a fine solution.

notatallshaw · 2025-11-02T14:54:12Z

I'm almost tempted to propose that arbitrary equality clauses should not be allowed to appear in the same specifier set as any other clause (ie it must appear alone). === matches exactly one string and one string only, so given a specifier set s with an arbitrary equality clause that matches v, adding another clause c can only either (1) cause s to continue to match v, or (2) cause s to match nothing.

PEP 440 says nothing about specifier sets, so the semantics of sets is the prerogative of packaging, however I don't want to break backwards compatibility, and this is allowed today, e.g.

>>> SpecifierSet('===1.0,>0.5').contains('1.0')
True

I don't think it's sane to have assert Specifier("!=1.0").contains("foobar"). This might lead to accidentally accepting invalid versions. The way I think of specifier set and arbitrary equality is that SpecifierSet starts with the universe of valid versions. Each non-arbitrary-equality clause added to the specifier set restricts the universe of versions. Adding an arbitrary equality clause has unique semantics, in that it widens the universe of versions to include exactly that version, regardless of what any other clause says.

I am okay with the choice that the specifier !=1.0 only acts on valid versions, not arbitrary strings, and therefore it excludes all arbitrary strings that don't conform to valid version semantics. I do think it reads awkwardly, but it is justifiable.

But I am not okay to say that SpecifierSet("===foo") has special semantics that expands the universe of versions beyond the empty specifier set SpecifierSet("") as I will explain.

If the goal is to not allow users to include arbitrary strings I think we should go back to them throwing an exception and then users can prevalidate their versions with Version. One of my goals here is to conform to the Python packaging spec which does allow for arbitrary strings as the result of valid specifiers.

But I don't think it's too bad to repair. I would state the following two invariants:

For any valid version v and specifiers A and B, if v is not satisfied by A, then v must also not be satisfied by A and B.

For any invalid version v and specifiers A and B, if v is satisfied by A, then v must also be satisfied by A and B.

I don't think this second invariant holds, but even if it did it still wouldn't achieve my other main goal.

I want to be able to consider specifier sets without considering what versions they act on, because I want to be able to implement resolution algorithms that can do some static analysis on the specifiers, and looking up what versions available is potentially an IO call.

I've already spent a lot of time reading the spec and conforming packaging to make sure pre-release specifiers don't have this "universe expanding" property, I am going to do my best to avoid it for arbitrary string versions also.

return False instead of raising for .contains with invalid version

0e353d0

add Specifier.filter tests

85bee6f

JP-Ellis mentioned this pull request Oct 7, 2025

fix(markers): only parse versions on certain keys #939

Merged

notatallshaw mentioned this pull request Oct 11, 2025

Fully cover handling arbitrary equality (===) in Specifier and SpecifierSet. #943

Open

notatallshaw self-requested a review October 23, 2025 23:16

Merge remote-tracking branch 'upstream/main' into contains-invalid-ve…

6a8721c

…rsion

handle invalid version case with prereleases=False

7530adf

Merge branch 'main' into contains-invalid-version

a6a956e

notatallshaw approved these changes Oct 25, 2025

View reviewed changes

notatallshaw merged commit 9983e4b into pypa:main Oct 25, 2025
39 checks passed

Liam-DeVoe deleted the contains-invalid-version branch October 26, 2025 02:19

notatallshaw mentioned this pull request Nov 1, 2025

New release for PEP 794 and packaging.pylock #950

Closed

notatallshaw mentioned this pull request Nov 2, 2025

Support arbitrary equality on arbitrary strings for Specifier and SpecifierSet's filter and contains method. #954

Merged

github-actions bot mentioned this pull request Feb 12, 2026

Bump packaging from 25.0 to 26.0 senzing-factory/dockerhub-util#176

Merged

cjwatson mentioned this pull request Mar 3, 2026

Tests fail with packaging 26.0 pdm-project/dep-logic#16

Open

Conversation

Liam-DeVoe commented Sep 9, 2025

Uh oh!

notatallshaw commented Sep 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Liam-DeVoe commented Oct 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

notatallshaw commented Oct 11, 2025

Uh oh!

notatallshaw commented Oct 23, 2025

Uh oh!

Liam-DeVoe commented Oct 23, 2025

Uh oh!

Liam-DeVoe commented Oct 23, 2025

Uh oh!

Liam-DeVoe commented Oct 24, 2025

Uh oh!

notatallshaw commented Oct 24, 2025

Uh oh!

Liam-DeVoe commented Oct 24, 2025

Uh oh!

Uh oh!

notatallshaw commented Oct 25, 2025

Uh oh!

Liam-DeVoe commented Oct 25, 2025

Uh oh!

notatallshaw commented Nov 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

notatallshaw commented Nov 1, 2025

Uh oh!

Liam-DeVoe commented Nov 1, 2025

Uh oh!

notatallshaw commented Nov 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

notatallshaw commented Sep 13, 2025 •

edited

Loading

Liam-DeVoe commented Oct 4, 2025 •

edited

Loading

notatallshaw commented Nov 1, 2025 •

edited

Loading

notatallshaw commented Nov 2, 2025 •

edited

Loading