Inconsistent results between version.parse and utils.parse_sdist_filename

[phaer]

Hello,

I stumbled upon differing interpretations in version.parse and utils.parse_sdist_filename when parsing the version part of the same sdist filename. To be honest, both of them are surprising to some extent. While parse seems to interpret the intent correctly, even though the "postN" part does not seem PEP440-compliant to me, I'd expect both functions to raise InvalidVersion here. At least the result of parse_sdist_filename seems broken.

Happy to try a PR, just wanted to know whether you share my understanding of the problem first :)

>>> from packaging.utils import parse_sdist_filename
>>> from packaging.version import parse

>>> parse_sdist_filename("cffi-1.0.2-2.tar.gz")
('cffi-1-0-2', <Version('2')>)
>>> parse("1.0.2-2")
<Version('1.0.2.post2')>

(probably related to #530)

[uranusjr]

According to the specification, the version part of the sdist filename must be normalised. The sdist name you provided is therefore considered malformed and the parse result unspecified.

[phaer]

The sdist name you provided is therefore considered malformed and the parse result unspecified.

Yes, that's my understanding as well. The weird thing for me is the difference between the two results, especially as the name part seems compliant.

I'd be more than happy with InvalidVersion raised or so.

[uranusjr]

The version parser accepts non-normalised versions. 1.0.2-2 is a valid version, only not normalised and cannot be used in the file name.

[phaer]

Ah got you, the former part was/is confusing for me. I understand now that this is either hard or impossible to solve in a generic way here.

In my specific case the problem is that utils.parse_sdist_filename didn't return InvalidVersion but 2 instead of 1.0.2.post2, causing it to be sorted before e.g. 1.7 et al during resolving a list of candidate packages from pypi.
Worked around it with a more specific regex to split name and version: i.e. (?P<name>.*)-(?P<version>\d+\..*) works as long as no package has a number between - and . in its name. Not beautiful, but might be good enough for others stumbling into this.

[uranusjr]

The problem is that cffi-1.0.2 is a valid package name, and 2 is a valid version string. The parser chose to return a reasonable result.