marker evaluation should allow prerelease versions

[graingert]

considering the requirement black==22.1.0; python_full_version >= "3.6.2" I would expect pip to install black on python 3.11.0a5 however I get:

$ pip install 'black==22.1.0; python_full_version >= "3.6.2"'
Ignoring black: markers 'python_full_version >= "3.6.2"' don't match your environment

looking at packaging.markers "python_full_version > '3.6.2' is excluding pre-release versions:

>>> import packaging.markers
>>> packaging.markers.Marker("python_full_version > '3.6.2'").evaluate({"python_full_version": "3.11.0a5"})
False
>>> packaging.markers.Marker("python_full_version > '3.6.2'").evaluate({"python_full_version": "3.11.0"})
True
>>> 

see also pypa/pip#10962 (comment)

[brettcannon]

The PEPs don't directly address this. PEP 508 for environment markers says that PEP 440 is followed for comparisons. PEP 440 for pre-releases has a concept of "already installed" (which we just got fixed for #505 and is not out yet).

We could probably interpret the Python version as "installed" in this instance. @pradyunsg or @uranusjr are usually the marker experts. 😁

[pradyunsg]

I think this is a bug, and allowing pre-releases here seems like a reasonable thing to do.

[jedie]

Think it's still a valid bug, see: pypa/pipenv#5972 (comment)

tl;td;

I get errors like this:

Ignoring beautiful-barcode: markers 'python_version >= "3.6" and python_full_version < "4.0.0"' don't match your environment
Ignoring beautifulsoup4: markers 'python_full_version >= "3.6.0"' don't match your environment
Ignoring charset-normalizer: markers 'python_full_version >= "3.7.0"' don't match your environment
Ignoring flake8: markers 'python_full_version >= "3.8.1"' don't match your environment
Ignoring isort: markers 'python_full_version >= "3.8.0"' don't match your environment

with Python 3.11.0 rc1 and 3.11.6+, but not with 3.11.5
Details from 3.11.6+:

Python 3.11.6+ (heads/3.11:79b81d1, Oct 11 2023, 13:42:51) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.version
'3.11.6+ (heads/3.11:79b81d1, Oct 11 2023, 13:42:51) [GCC 11.4.0]'
>>> sys.version_info
sys.version_info(major=3, minor=11, micro=6, releaselevel='final', serial=0)

It happens with current pip version 23.2.1

[pradyunsg]

IIUC, pipenv maintains their own fork of pip. I suggest that you try and get a confirmation from the maintainers there about the source of the issue before reaching out here / to pip.

If it's indeed a bug, I'd appreciate it if you could file a new issue for it and include a reproducer using just packaging to describe the behaviour you see vs what you expect to see.

[matteius]

FWIW, pipenv's version of packaging is unmodified comes from pip's _vendor packaging, and where I believe the issue happens is in 7-8 year old code, if the version being compared doesn't end in a number, the comparison fails, which is what I believe this original issue report was about: https://github.com/pypa/pip/blame/main/src/pip/_vendor/packaging/markers.py#L189-L201

[pradyunsg]

Ah, so this is #678.