Support for integer versions (eg. systemd-python-234.tar.gz)?

[bsiggers]

At the moment, the version of systemd-python-234.tar.gz is returned as None, with the 234 being currently included in the package name. However according to PEP-0440, having an integer version, while being a bit unusual, is still valid (https://www.python.org/dev/peps/pep-0440/#id22), and passes is_canonical here: https://www.python.org/dev/peps/pep-0440/#id79

I've raised an issue for this to discuss, as there is at least one existing case used in test_guess_name_version_from_filename which will be invalidated (ocflib-3-4.tar.gz, here) if we changed this, so wanted to make sure that we are in agreement before I make a PR.

Relevant package for this case in pypi.org (systemd-python) is here.

[asottile]

Since .tar.gz doesn't have a rigid naming scheme the current approach is just a guess. Any improvements to the guess which pass tests would be appreciated :)

[bsiggers]

Thanks @asottile. For the existing ocflib-3-4.tar.gz test case, where does that particular use case come from? In pypi.org the versions for ocflib look like they are now compliant (https://pypi.org/project/ocflib/#files)

[asottile]

iirc it was adapted from a (broken) internal package which had version='3-4'. with the move to warehouse I think most of the packages which weren't installable were pulled.

The actual package in question wasn't ocflib, but that was a short name that got used for the testcase to demonstrate the specific issue

[bsiggers]

Ok, will take a stab at this.

[asottile]

fwiw it looks like packaging.utils.parse_sdist_filename gets this right -- would be a quick patch