Local version identifiers parse as legacy version

[gaborbernat]

>>> from packaging.specifiers import Specifier, LegacySpecifier

>>> LegacySpecifier('>= 4.0.0a2.dev79+g7a07b5b.d20201128')
<LegacySpecifier('>=4.0.0a2.dev79+g7a07b5b.d20201128')>

>>> Specifier('>= 4.0.0a2.dev79+g7a07b5b.d20201128')
Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "/lib/python3.9/site-packages/packaging/specifiers.py", line 112, in __init__
    raise InvalidSpecifier("Invalid specifier: '{0}'".format(spec))
packaging.specifiers.InvalidSpecifier: Invalid specifier: '>= 4.0.0a2.dev79+g7a07b5b.d20201128'

cc @di @pradyunsg

Even though https://www.python.org/dev/peps/pep-0440/#local-version-identifiers makes the version above valid. https://pypi.org/project/setuptools-scm/ is generating such versions. Especially important due to #321

[uranusjr]

Local version identifiers can be parsed correctly:

>>> from packaging import version
>>> version.parse('4.0.0a2.dev79+g7a07b5b.d20201128')
<Version('4.0.0a2.dev79+g7a07b5b.d20201128')>

But PEP 440 says that:

Inclusive ordered comparison
[…] Local version identifiers are NOT permitted in this version specifier.

Your specifier is therefore not a valid PEP 440 version specifier, and thus parsed as legacy.

[gaborbernat]

Eh, ok. So why would it not be a valid case to have a local version identifier within a version specifier?

[uranusjr]

I don’t know. My guess is that since the local version segment has no ordering, it does not make sense to do comparison on them (which would incorrectly hint that they have a part in the comparison logic).

[gaborbernat]

I guess only == would make sense due to that 🤔 Which seems to pass.