You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Python version ending with plus sign not compatible with PEP 508 python_full_version marker #99968
When building an untagged version of CPython, the resulting version ends with a plus sign, e.g. 3.11.0+. This version doesn't comply with PEP 440. As mentioned in #88166 (comment) PEP 440 does only apply to Python packages but not to CPython itself. However, a CPython version that doesn't comply with PEP 440 leads to unwanted side effects considering the python_full_version environment marker from PEP 508.
According to PEP 508 python_full_version is equal to platform.python_version() which is 3.11.0+ in my example.
Further, PEP 508 says:
The <version_cmp> operators use the PEP 440 version comparison rules when those are defined (that is when both sides have a valid version specifier). If there is no defined PEP 440 behaviour and the operator exists in Python, then the operator falls back to the Python behaviour.
That means an environment marker like python_full_version >= "3.9.0" is fulfilled for Python 3.11.0 because a PEP 440 version comparison is performed. However, it is not fulfilled for Python 3.11.0+ because 3.11.0+ is not a valid version and thus a string comparison is performed.
This has also practical implications. When trying to pip install a requirement with such a marker, pip says markers 'python_full_version >= "3.9.0"' don't match your environment. And if I understand correctly, it's right about that. However, that can't be intentional, can it? Wouldn't it be better to make sure that CPython versions always comply with PEP 440?
It seems the + is added by the release manager in a manual commit, so the fix is to have a discussion with the upcoming release manager, and request that they use .dev or +dev in the future.
That future release managers are @hugovk and @savannahostrowski. tl;dr: Non-PEP 440 Python versions (those with a +) cause problems in package managers as they breaks PEP 508's assumption that python_full_version is a PEP 440 version.
+{something} would be the preference, as under PEP 440 version specifiers ==3.17.0 matches the version 3.17.0+dev (a local version) but not the version 3.17.0.dev (a pre release version).
Chatted with Hugo about this and +dev looks like the right suffix (sorts correctly per PEP 440 local version semantics). I'll take a look this week, targeting at least 3.16 onward.
Reacted by Damian Shaw, konsti, Hugo van Kemenade and Stefano Rivera
Hugo and I opted to have this apply for upcoming 3.15 releases as well to get faster feedback on the fix. Both python/release-tools#394 and python/peps#4983 have been merged, so any upcoming 3.15+ release will get the +dev suffix.
Reacted by Damian Shaw and Randy Döring
Reacted by konsti, Edgar Ramírez Mondragón, Bartosz Sokorski and Stefano Rivera
Activity
hugovk commentedon Feb 19, 2023
Thanks for opening the issue, see also pypa/packaging#678 (comment) for further discussion.
konstin commentedon Feb 20, 2024
This causes problems in uv because it breaks PEP 508 compliant marker implementations (astral-sh/uv#1357)
strip trailing `+` from version number of local Python builds
strip trailing `+` from version number of local Python builds (#1771)
env: add support for untagged CPython builds where platform.python_ve…
env: add support for untagged CPython builds where platform.python_ve…
env: add support for untagged CPython builds where platform.python_ve…
env: add support for untagged CPython builds where platform.python_ve…
env: add support for untagged CPython builds where platform.python_ve…
env: add support for untagged CPython builds where platform.python_ve…
jawhien commentedon Jun 22, 2024
Tell me how to build from the source code so that the version does not have this sign (+)?
stefanor commentedon May 15, 2026
It seems the
+is added by the release manager in a manual commit, so the fix is to have a discussion with the upcoming release manager, and request that they use.devor+devin the future.konstin commentedon May 16, 2026
That future release managers are @hugovk and @savannahostrowski. tl;dr: Non-PEP 440 Python versions (those with a
+) cause problems in package managers as they breaks PEP 508's assumption thatpython_full_versionis a PEP 440 version.notatallshaw commentedon May 16, 2026
+{something}would be the preference, as under PEP 440 version specifiers==3.17.0matches the version3.17.0+dev(a local version) but not the version3.17.0.dev(a pre release version).savannahostrowski commentedon May 24, 2026
Chatted with Hugo about this and
+devlooks like the right suffix (sorts correctly per PEP 440 local version semantics). I'll take a look this week, targeting at least 3.16 onward.savannahostrowski commentedon May 27, 2026
Hugo and I opted to have this apply for upcoming 3.15 releases as well to get faster feedback on the fix. Both python/release-tools#394 and python/peps#4983 have been merged, so any upcoming 3.15+ release will get the
+devsuffix.hugovk commentedon Jun 3, 2026
Following yesterday's 3.15.0b2 release, https://github.com/python/cpython/tree/3.15 is now:
gh-99968: FAQ: dev versions end in `+dev` (#153262)
[3.15] gh-99968: FAQ: dev versions end in `+dev` (GH-153262) (#154268)