pip-audit crashes with unusual Python versions

[di]

does #139 also address python itself having a version like 3.9.7+? this is what development python versions like 3.9-dev built via pyenv end up with – not sure if this is python's or pyenv's doing.

the stack trace looks different:

$ pip-audit
Traceback (most recent call last):
  File "bin/pip-audit", line 5, in <module>
    from pip_audit._cli import audit
  File "lib/python3.9/site-packages/pip_audit/_cli.py", line 15, in <module>
    from pip_audit._audit import AuditOptions, Auditor
  File "lib/python3.9/site-packages/pip_audit/_audit.py", line 9, in <module>
    from pip_audit._dependency_source import DependencySource
  File "lib/python3.9/site-packages/pip_audit/_dependency_source/__init__.py", line 13, in <module>
    from .resolvelib import ResolveLibResolver  # noqa: F401
  File "lib/python3.9/site-packages/pip_audit/_dependency_source/resolvelib/__init__.py", line 5, in <module>
    from .resolvelib import ResolveLibResolver, ResolveLibResolverError  # noqa: F401
  File "lib/python3.9/site-packages/pip_audit/_dependency_source/resolvelib/resolvelib.py", line 16, in <module>
    from .pypi_provider import PyPIProvider
  File "lib/python3.9/site-packages/pip_audit/_dependency_source/resolvelib/pypi_provider.py", line 31, in <module>
    PYTHON_VERSION = Version(python_version())
  File "lib/python3.9/site-packages/packaging/version.py", line 266, in __init__
    raise InvalidVersion(f"Invalid version: '{version}'")
packaging.version.InvalidVersion: Invalid version: '3.9.7+'

Originally posted by @wbolster in #138 (comment)

[di]

We probably shouldn't be attempting to parse platform.python_version as a packaging.version.Version, or the requires-python field as a packaging.specifiers.SpecifierSet -- they are tantalizingly similar, but not guaranteed to be compatible. I'm guessing pip has some logic to deal with weird Python versions like this, that we should try to emulate.

[woodruffw]

Yeah, this is an interesting case: packaging provides SpecifierSet for this purpose, and SpecfierSet wraps Specifier which explicitly only supports PEP 440-style versions (link). So that part, at least, should be sound.

I'll try using a source other than python.platform_version for the Python version, like sys.version. Although, interestingly, python.platform_version's documentation says that it always returns a string in the form major.minor.patchlevel. So this is arguably a standard library break by pyenv, albeit one we're probably going to have to live with.

[di]

PEP 440 is for package versions though -- AFAIK, there is no such guarantee on the Python version.

[woodruffw]

Ah, yeah. Okay, I'll look at avoiding it entirely as well -- we only use it for performing an initial filter pass on the distributions collected from PyPI.

[woodruffw]

Okay, I did some additional PEP-standards-lawyering:

1. The data-requires-python attribute is specified in PEP 503, which says that it's identical in format to the Requires-Python field specified in PEP 345
2. PEP 345 says that every version number in Requires-Python must be in the format specified in PEP 440.

So the state of things is that Requires-Python (and thus data-requires-python) are always PEP-440 compliant, even when the version provided by platform.python_version or any other source isn't. So I think the appropriate behavior here is probably to retain our use of SpecifierSet, but be more conservative about how we produce a Version object from the running Python.