All cpython-dev builds have invalid versions

[ssbarnea]

When installing devel builds using such pyenv install 3.11-dev, you endup with a python installation that has a version string that cannot be evaluated as a Version.

This breaks PEP-508 by bringing this invalid string into python_full_version field, which can be used even inside package metadata.

As a side effect of this, packages might fail to correctly evaluate environment markers or even break tools like pdm.

AFAIK, this is unlikely to be fixable by packages involved, primary packaging, as the specification (final since 2015) is very clear regarding the fact that python_full_version is loaded directly from the output of platform.python_version().

Shortly, the only way to avoid having a broken python installation from source, is to ensure that platform.python_version() returns a valid version string, one that can be loaded by Version().

from packaging.version import Version
import platform

x = Version(platform.python_version())
#     raise InvalidVersion(f"Invalid version: '{version}'")
# packaging.version.InvalidVersion: Invalid version: '3.11.0+'

[ssbarnea]

What makes the situation even worse is that I used the -dev installations a lot as these were allowing me to install and upgrade minor version of python without having to reinstall all dependencies and worse to re-configure hundreds of vscode projects/workspaces as the path to python would change when you do a minor version update.

Basically by installing 3.11-dev you do not need to update anything when 3.11.2 is released, you just to a force install and all the paths remain stable.

I know that this was a side-effect of the decision of pyenv to prevent having generic "X.Y" versions, without minor version being listed.

[ssbarnea]

@native-api Do you think that the non compliant version of dev pythons should be better raised a pytest bug instead of a discussion?

[native-api]

We do not (purposefully) touch anything about Python's reported version name. The "3.11.1+" comes from CPython's built-in logic, specifically, for 3.11 as of now, from https://github.com/python/cpython/blob/8cf8a6820e3fa885ac6159b8002f5e8d7834ca83/Include/patchlevel.h#L26 .

For this reason, I think it's not designed to be parsed as you've tried to.

To my knowledge, "+" after a release number is a more-or-less standard way to designate a post-release development branch.