Install of 6.47.2 fails with pipenv

[cordery]

It appears that the following line in hypothesis-python/setup.py causes installation with pipenv (2022.6.7) to fail:

hypothesis/hypothesis-python/setup.py

Line 105 in b73d6fd

"exceptiongroup>=1.0.0rc8 ; python_version<'3.11.0b1'",

The pipenv traceback is:

Traceback (most recent call last):
  File "/Users/andrewcordery/.local/pipx/venvs/pipenv/lib/python3.9/site-packages/pipenv/resolver.py", line 856, in <module>
    main()
  File "/Users/andrewcordery/.local/pipx/venvs/pipenv/lib/python3.9/site-packages/pipenv/resolver.py", line 842, in main
    _main(
  File "/Users/andrewcordery/.local/pipx/venvs/pipenv/lib/python3.9/site-packages/pipenv/resolver.py", line 822, in _main
    resolve_packages(
  File "/Users/andrewcordery/.local/pipx/venvs/pipenv/lib/python3.9/site-packages/pipenv/resolver.py", line 783, in resolve_packages
    results = clean_results(results, resolver, project, dev)
  File "/Users/andrewcordery/.local/pipx/venvs/pipenv/lib/python3.9/site-packages/pipenv/resolver.py", line 652, in clean_results
    entry_dict = translate_markers(entry.get_cleaned_dict(keep_outdated=False))
  File "/Users/andrewcordery/.local/pipx/venvs/pipenv/lib/python3.9/site-packages/pipenv/resolver.py", line 277, in get_cleaned_dict
    if self.original_markers and not self.markers:
  File "/Users/andrewcordery/.local/pipx/venvs/pipenv/lib/python3.9/site-packages/pipenv/resolver.py", line 634, in __getattribute__
    return super().__getattribute__(key)
  File "/Users/andrewcordery/.local/pipx/venvs/pipenv/lib/python3.9/site-packages/pipenv/resolver.py", line 239, in original_markers
    original_markers, lockfile_dict = self.get_markers_from_dict(self.lockfile_dict)
  File "/Users/andrewcordery/.local/pipx/venvs/pipenv/lib/python3.9/site-packages/pipenv/resolver.py", line 212, in get_markers_from_dict
    markers.add(normalize_marker_str(entry_dict["markers"]))
  File "/Users/andrewcordery/.local/pipx/venvs/pipenv/lib/python3.9/site-packages/pipenv/vendor/requirementslib/models/markers.py", line 692, in normalize_marker_str
    parts = cleanup_pyspecs(pyversion)
  File "/Users/andrewcordery/.local/pipx/venvs/pipenv/lib/python3.9/site-packages/pipenv/vendor/requirementslib/models/markers.py", line 286, in cleanup_pyspecs
    for op_and_version_type, versions in _group_by_op(tuple(specs)):
  File "/Users/andrewcordery/.local/pipx/venvs/pipenv/lib/python3.9/site-packages/pipenv/vendor/requirementslib/models/markers.py", line 200, in _group_by_op
    specs = [_get_specs(x) for x in list(specs)]
  File "/Users/andrewcordery/.local/pipx/venvs/pipenv/lib/python3.9/site-packages/pipenv/vendor/requirementslib/models/markers.py", line 200, in <listcomp>
    specs = [_get_specs(x) for x in list(specs)]
  File "/Users/andrewcordery/.local/pipx/venvs/pipenv/lib/python3.9/site-packages/pipenv/vendor/requirementslib/models/markers.py", line 193, in _get_specs
    result.append((spec.operator, _tuplize_version(spec.version)))
  File "/Users/andrewcordery/.local/pipx/venvs/pipenv/lib/python3.9/site-packages/pipenv/vendor/requirementslib/models/markers.py", line 124, in _tuplize_version
    return tuple(int(x) for x in filter(lambda i: i != "*", version.split(".")))
  File "/Users/andrewcordery/.local/pipx/venvs/pipenv/lib/python3.9/site-packages/pipenv/vendor/requirementslib/models/markers.py", line 124, in <genexpr>
    return tuple(int(x) for x in filter(lambda i: i != "*", version.split(".")))
ValueError: invalid literal for int() with base 10: '0b1'
✘ Locking Failed!

The relevant line in pipenv is attempting to turn all parts of the version into integers: https://github.com/pypa/pipenv/blob/2482e2d3a49fec6830a80606c90c6be9d6bf7946/pipenv/vendor/requirementslib/models/markers.py#L124

I'm not sure the python_version marker is intended to support full version numbers including the beta suffix. Looking at https://peps.python.org/pep-0508/ it seems to indicate you'd need to use python_full_version to do that, which is perhaps why pipenv is attempting to turn each part of the python_version version string into an integer.

[Zac-HD]

I consider this a bug in pipenv, but unfortunately one that we might need to work around downstream too.

[JacobHayes]

I think the linked code (requirementslib) is vendored, I opened an issue there, but maybe they'll point out the python_version vs python_full_version thing as well (though the breaking code seems to be a pretty general function).

[cordery]

The reason I mention that the python_version marker may not be intended to support full versions including beta is that PEP508 describes python_version as being equivalent to '.'.join(platform.python_version_tuple()[:2]), so assuming that the 'b' beta indicator is always on the patch portion of the version string, it would never be included here.

That said, looking at the requirementslib code, it appears that they do not need to be converting all parts of the version to an integer, only the first two. Additionally, they do automatically correct 'python_version' to 'python_full_version' if it includes three version parts, but that only happens after the forced conversion to integers.

On a rather amusing note, at the moment you cannot pipenv install -e .[dev,tests,typing] to get a local dev setup of requirementslib going because..... requirementslib uses hypothesis for tests! https://github.com/sarugaku/requirementslib/blob/main/setup.cfg#L67

To summarize: requirementslib shouldn't crash on parsing python_version<'3.11.0b1'" but strictly speaking it probably shouldn't pay attention to the '.0b1' portion either when specified in python_version.