Future Python versions might be problematic with the definition of Environment Marker Variable `python_version`

[finefoot]

There might be a problem with

packaging/packaging/markers.py

Line 267 in c22fbd8

"python_version": platform.python_version()[:3],

in the future.

The line is using the definition of the Environment Marker Variable python_version according to PEP 508. But what if the Python version will consist of more than 3 characters?

I originally posted this as a question on Stack Overflow https://stackoverflow.com/questions/48119291/whats-with-the-definition-of-environment-marker-variable-python-version-in-pe Just as Martijn Pieters wrote there, something like ".".join(platform.python_version_tuple()[:2]) would fix the problem.

I guess, the PEP would have to be changed first?

[uranusjr]

See also pypa/pip#6730 (python3.10: environment markers assume python3.1)

There are two parts to this problem though. This issue covers the first. I believe this is easily amendable, and plan to submit a PR shortly for it.

The second part is more complicated. Currently marker comparison simply use Python’s string comparison logic, so even if we correctly read python_version, '3.10' is still < '3.9'. PEP 508 does say that markers should use version comparison, but its definition of version is much looser than packaging.version.Version (i.e. PEP 440), thus I’m not entirely sure whether it’d work to simply apply packagin.version.parse_version on markers. Some doubts from the top of my head:

• Is there guarentee that python_version and python_full_version would be parsable with PEP 440? (Or at least work reasonably as LegacyVersion.)
• Should we just compare everything as version, or should there be rules to treat certain markers as versions, and others as strings?

[pradyunsg]

Let's stick with solving this in #165 for now.