Marker referencing 'platform_release' fails to evaluate on Linux systems with non-PEP 440 kernel versions

[diazona]

In a conversation on Mastodon, @kevinbowen777 reported an error with a failing version comparison when installing py5 with pdm. With @py5coding and myself, we tracked the cause to markers like platform_release >= "20.0" and sys_platform == "darwin" that appear in the pdm lock file. Specifically, on Linux, platform_release evaluates to the full Linux kernel version as returned by uname -r, which might be something like 6.1.0-17-amd64 (on Kevin's system) or 6.7.0-gentoo (on mine), and so when packaging applies PEP 440 version comparison logic to that version number, it raises an InvalidVersion error.

Here's a simple reproduction on my system:

>>> import packaging.markers
>>> marker = packaging.markers.Marker('platform_release >= "20.0"')
>>> packaging.markers.default_environment()
{'implementation_name': 'cpython', 'implementation_version': '3.12.1', 'os_name': 'posix', 'platform_machine': 'x86_64', 'platform_release': '6.7.0-gentoo', 'platform_system': 'Linux', 'platform_version': '#1 SMP PREEMPT_DYNAMIC Sun Jan 14 21:02:35 PST 2024', 'python_full_version': '3.12.1', 'platform_python_implementation': 'CPython', 'python_version': '3.12', 'sys_platform': 'linux'}
>>> m.evaluate()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.12/site-packages/packaging/markers.py", line 252, in evaluate
    return _evaluate_markers(self._markers, current_environment)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/site-packages/packaging/markers.py", line 158, in _evaluate_markers
    groups[-1].append(_eval_op(lhs_value, op, rhs_value))
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/site-packages/packaging/markers.py", line 116, in _eval_op
    return spec.contains(lhs, prereleases=True)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/site-packages/packaging/specifiers.py", line 568, in contains
    normalized_item = _coerce_version(item)
                      ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/site-packages/packaging/specifiers.py", line 36, in _coerce_version
    version = Version(version)
              ^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/site-packages/packaging/version.py", line 200, in __init__
    raise InvalidVersion(f"Invalid version: '{version}'")
packaging.version.InvalidVersion: Invalid version: '6.7.0-gentoo'

I know it's not terribly common for packages to use the platform_release marker, but evidently it does happen; in this case when installing py5, something is conditionally depending on pyobjc and is using platform_release to express that condition. And I didn't find anything in the documentation indicating that this sort of thing shouldn't be allowed. So it certainly at least looks like an issue that needs to be worked around.

This is pretty similar to #678, but that issue was about the Python runtime version, where there's a bit of an argument to be made that CPython should stick to PEP 440-compatible version numbers. I'm pretty sure that argument isn't going to fly for distribution-packaged Linux kernel versions. I wasn't sure if you'd rather have a separate issue or just a comment on #678, but I figured I'd start with this and you can absorb it into that other issue if you want.

---

Original example with pdm and py5

$ pdm init --python python3.12 --lib --backend pdm-backend --non-interactive
Creating a pyproject.toml for PDM...
Virtualenv is created successfully at /home/diazona/tmp/py5_test/.venv
Project is initialized successfully
$ pdm add --no-sync py5
Adding packages to default dependencies: py5
🔒 Lock successful
Changes are written to pyproject.toml.
$ pdm install -v
STATUS: Resolving packages from lockfile...
Traceback (most recent call last):
  File "/home/diazona/.local/bin/pdm", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/home/diazona/.local/pipx/venvs/pdm/lib/python3.12/site-packages/pdm/core.py", line 288, in main
    return Core().main(args or sys.argv[1:])
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/diazona/.local/pipx/venvs/pdm/lib/python3.12/site-packages/pdm/core.py", line 208, in main
    raise cast(Exception, err).with_traceback(traceback) from None
  File "/home/diazona/.local/pipx/venvs/pdm/lib/python3.12/site-packages/pdm/core.py", line 203, in main
    self.handle(project, options)
  File "/home/diazona/.local/pipx/venvs/pdm/lib/python3.12/site-packages/pdm/core.py", line 157, in handle
    command.handle(project, options)
  File "/home/diazona/.local/pipx/venvs/pdm/lib/python3.12/site-packages/pdm/cli/commands/install.py", line 100, in handle
    actions.do_sync(
  File "/home/diazona/.local/pipx/venvs/pdm/lib/python3.12/site-packages/pdm/cli/actions.py", line 222, in do_sync
    candidates = resolve_candidates_from_lockfile(project, requirements, groups=list(selection))
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/diazona/.local/pipx/venvs/pdm/lib/python3.12/site-packages/pdm/cli/actions.py", line 154, in resolve_candidates_from_lockfile
    return {
           ^
  File "/home/diazona/.local/pipx/venvs/pdm/lib/python3.12/site-packages/pdm/models/repositories.py", line 605, in evaluate_candidates
    and not can.req.marker.evaluate(self.environment.marker_environment)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/diazona/.local/pipx/venvs/pdm/lib/python3.12/site-packages/pdm/models/markers.py", line 50, in evaluate
    return self.inner.evaluate(environment)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/diazona/.local/pipx/venvs/pdm/lib/python3.12/site-packages/dep_logic/markers/multi.py", line 139, in evaluate
    return all(m.evaluate(environment) for m in self.markers)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/diazona/.local/pipx/venvs/pdm/lib/python3.12/site-packages/dep_logic/markers/multi.py", line 139, in <genexpr>
    return all(m.evaluate(environment) for m in self.markers)
               ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/diazona/.local/pipx/venvs/pdm/lib/python3.12/site-packages/dep_logic/markers/single.py", line 50, in evaluate
    return pkg_marker.evaluate(environment)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/diazona/.local/pipx/venvs/pdm/lib/python3.12/site-packages/packaging/markers.py", line 252, in evaluate
    return _evaluate_markers(self._markers, current_environment)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/diazona/.local/pipx/venvs/pdm/lib/python3.12/site-packages/packaging/markers.py", line 158, in _evaluate_markers
    groups[-1].append(_eval_op(lhs_value, op, rhs_value))
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/diazona/.local/pipx/venvs/pdm/lib/python3.12/site-packages/packaging/markers.py", line 116, in _eval_op
    return spec.contains(lhs, prereleases=True)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/diazona/.local/pipx/venvs/pdm/lib/python3.12/site-packages/packaging/specifiers.py", line 568, in contains
    normalized_item = _coerce_version(item)
                      ^^^^^^^^^^^^^^^^^^^^^
  File "/home/diazona/.local/pipx/venvs/pdm/lib/python3.12/site-packages/packaging/specifiers.py", line 36, in _coerce_version
    version = Version(version)
              ^^^^^^^^^^^^^^^^
  File "/home/diazona/.local/pipx/venvs/pdm/lib/python3.12/site-packages/packaging/version.py", line 200, in __init__
    raise InvalidVersion(f"Invalid version: '{version}'")
packaging.version.InvalidVersion: Invalid version: '6.7.0-gentoo'

It's worth noting that we haven't figured out how to reproduce this with any other package installer besides pdm. We haven't figured out why exactly that is; evidently there's something that pdm is doing and others don't which is involved in triggering the error. But, considering the simple example I posted above, this clearly doesn't need pdm to be reproducible, and it didn't seem like pdm is using Marker.evaluate() incorrectly, which is why I'm reporting it here rather than to pdm.