Dependency specifiers: `in` and `not in` on Version fields

Packaging
1

(Follow up to Spec change/bugfix: dependency specifiers simplification (PEP 508))

One of the cleanups/clarifications we made for environment marker evaluation semantics earlier this year was this note regarding Version fields like python_version:

Note that in and not in containment checks are NOT valid for Version fields and publishing tools SHOULD emit an error, index servers MAY disallow uploads containing such environment markers, while locking and installation tools MAY treat them as always being False.

While looking at migrating a process from pip-compile to pipenv requirements, I encountered the following pseudo-set notation that relies on the historical Version → String fallback behaviour to evaluate the environment marker correctly:

colorama==0.4.6; python_version >= '2.7' and python_version not in '3.0, 3.1, 3.2, 3.4, 3.5, 3.6'

(This is a translation of colorama’s Requires-Python field, which specifies !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*, !=3.4.*, !=3.5.*, !=3.6.*, >=2.7, into an environment marker form)

While doing that for python_full_version would always have been invalid (as it doesn’t handle pre-releases or maintenance updates correctly), that concern doesn’t apply for python_version, as that’s explicitly defined as only including the first two parts of the Python version number, regardless of the exact patch release or pre-release details in the full version number.

For this specific example, “always return False for invalid operators” logic would give the wrong answer (omitting colorama even when it’s a valid inclusion).

I’m leaning towards filing an issue with pipenv to look into updating the way Requires-Python is translated into environment markers, but wanted to bring it up here first as I think this is a genuine incompatibility in the spec update that we didn’t identify at the time.