Arbitrary equality parsed different using `Specifer` and `SpecifierSet`

[BarakKatzir]

I noticed a difference between how Sepcifier and SpecifierSet parses the arbitrary equality.
The Specifier's regex accepts almost any character, including commas:

packaging/src/packaging/specifiers.py

Line 122 in f585376

[^\s;)]* # The arbitrary version can be just about anything,

This can lead to funky results such as:

>>> from packaging.specifiers import Specifier, SpecifierSet
>>> spec = Specifier('===hello,')
>>> spec_set1 = SpecifierSet([spec])
>>> spec_set2 = SpecifierSet('===hello,')
>>> # both seem identical but are not equal
>>> print(repr(spec_set1))
<SpecifierSet('===hello,')>
>>> print(repr(spec_set2))
<SpecifierSet('===hello')>
>>> assert spec_set1 != spec_set2

Or if the user is not careful, two specifier are parsed as a single arbitrary equality specifier:

>>> Specifier('===moo,<=0.1')
<Specifier('===moo,<=0.1')>
>>> _.operator
'==='

I'm not sure I understand the specification (for version specifiers) correctly, but I expected that arbitrary equality values would not be allowed to contain commas. I think this is a bug, but I'm not sure.

The commas are handled here:

packaging/src/packaging/specifiers.py

Line 722 in f585376

split_specifiers = [s.strip() for s in specifiers.split(",") if s.strip()]

I checked this behavior on packaging version 25.0

[notatallshaw]

The specification allows arbitrary equality to be any string, there is no restriction.

[BarakKatzir]

Thanks for the clarification.

In that case, am I correct in understanding that
SpecifierSet('===0.1,<1.0') should be a set of with a single specifier of arbitrary equality with version '0.1<1.0'? Currently, that is not the case and the set includes two specifiers.

[notatallshaw]

It's a good question and I'm not sure.

My initial guess is that specifier "sets" are not defined by the spec, but are there to support dependency specifiers, so whatever the rules on separating them should align with dependency specifiers spec (even though there's no explicit dependency): https://packaging.python.org/en/latest/specifications/dependency-specifiers/

I'm not that familiar with this part of the spec, so I'll do a bit of reading when I get a chance.

[notatallshaw]

Okay, I've had a bit of a chance to evaluate this, and I would say that the version specifier specification and the dependency specifier specification are slightly at odds with each other.

I investigated using the the complete grammar provided: https://packaging.python.org/en/latest/specifications/dependency-specifiers/#complete-grammar

Firstly, the dependency specifier grammar currently fails to parse any arbitrary equality specifiers due to a mistake in the ordering of the version specifier operators: pypa/packaging.python.org#1969

Secondly, while the dependency specifier spec states:

Versions may be specified according to the rules of the Version specifier specification.

It's grammar is significantly more restrictive:

version_cmp   = wsp* '<' | '<=' | '!=' | '==' | '>=' | '>' | '~=' | '==='
version       = wsp* ( letterOrDigit | '-' | '_' | '.' | '*' | '+' | '!' )+
version_one   = version_cmp version wsp*
version_many  = version_one (',' version_one)* (',' wsp*)?

One by one this tells us:

1. The comparison symbols can only be one of: <, <=, !=, ==, >=, >, ~=, or ===
2. The versions can only be made of up of: letters, digits, -, _, ., *, +, or !
3. One version specifier is a comparison symbol followed by a version
4. Version specifiers can be listed as one or more, separated by commas

So ultimately, even though no such restriction exists in the version specifier specification for arbitrary equality, the grammar of the dependency specifier specification does now allow for a version to contain anything more than letters, digits, -, _, ., *, +, and !.

This leads to the inconsistency you have found between Specifier which comes from the version specifier specification, and SpecifierSet that appears to be to support dependency specifiers.

I don't think there is any action to do here, I do not think that supporting commas in the versions of arbitrary equality for SpecifierSets is something we should strive toward, and I do not want to change the specification for specifiers to disallow commas. I think we should just leave the comma as a character in limbo and advise users to avoid them for the purpose of versions in arbitrary equality, just as we already discourage arbitrary equality itself.

[BarakKatzir]

Thank you very much for checking!

This behavior is a bit surprising to me, but I guess arbitrary equality is an anomaly in the spec by definition :)

Regarding the warning to users, in addition to avoiding , I'd add ; and ). These two characters these are not supported by Specifier, and if I understand correctly for similar reasons that SpecifierSet does not support , (as per comment here:

packaging/src/packaging/specifiers.py

Line 122 in f585376

[^\s;)]* # The arbitrary version can be just about anything,

)

If you'd like I'm willing to open a PR and add this warning in an appropriate place, wherever that is.
I opened this issue after reading the version specifier spec and packaging source code, not sure if either of these are good places.

[notatallshaw]

in addition to avoiding , I'd add ; and ). These two characters these are not supported by Specifier, and if I understand correctly for similar reasons that SpecifierSet does not support ,

I'm sure that it's written that way because in practice those characters can't be used as part of a Dependency specifier, but unlike SpecifierSet which is not directly defined in the specification but closely matched Dependency specifiers, Specifier is clearly meant to be an implementation of the Version specifier from the specification, and therefore I would consider not allowing ; or ) as not spec compliant.

Now, I don't think we should fix it, but I also don't think we should explicitly document it.

If you'd like I'm willing to open a PR and add this warning in an appropriate place, wherever that is.

At least for SpecifierSet, and maybe for Specifier, I would only want to document that because the grammar of Dependency specifiers only explictly allows letters, digits, -, _, ., *, +, or !, so any other symbol MAY not work.

I'm not exactly sure where that would be documented though.