Closed freakboy3742 closed 1 month ago
Tagging @sarayourfriend since you were working on this recently; no obligation to look into it, but if you've got the interest and spare cycles.
Interesting! I think it will be an easy fix by passing preeleases=True
to spec.contains
. I'll try that out and open a PR here shortly if it works.
I'll drop a note here to the PyPA docs on pre-release handling in version specifiers, because the defaults/intentions here were new to me: https://packaging.python.org/en/latest/specifications/version-specifiers/#handling-of-pre-releases
It's somewhat different for Briefcase's requires-python
check because it isn't trying to resolve a particular version of a dependency, rather just checking that the active one matches the specifier. In that case, "accept already installed pre-releases for all version specifiers" from the set of default behaviours makes sense to follow.
Describe the bug
2029 added support for PEP 621
requires-python
declarations. However, these version checks appear to always fail if the Python version is a prerelease.Steps to reproduce
In this CI run, using Python 3.14.0a1, there are 4 test failures:
Expected behavior
3.14.0a1 should pass
requires-python
checks that require!=3.2
,>3.2
, and<3.100
.Screenshots
No response
Environment
Logs
Additional context
This came up in the context of trying to add Python 3.14 to Briefcase's CI matrix.