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

**URL:** <https://discuss.python.org/t/dependency-specifiers-in-and-not-in-on-version-fields/108340>\
**Category:** Packaging\
**Created:** [July 31, 2026, 4:20am UTC](https://discuss.python.org/t/dependency-specifiers-in-and-not-in-on-version-fields/108340 "2026-07-31T04:20:19Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![ncoghlan](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ncoghlan/32/14266_2.png) [@ncoghlan](https://discuss.python.org/u/ncoghlan)\
**Post date:** [July 31, 2026, 4:20am UTC](https://discuss.python.org/t/dependency-specifiers-in-and-not-in-on-version-fields/108340/1 "2026-07-31T04:20:19Z")

</div>

(Follow up to [Spec change/bugfix: dependency specifiers simplification (PEP 508)](https://discuss.python.org/t/spec-change-bugfix-dependency-specifiers-simplification-pep-508/105203))

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:

```python
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.

---

<div class="post-metadata">

**Author:** ![ncoghlan](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ncoghlan/32/14266_2.png) [@ncoghlan](https://discuss.python.org/u/ncoghlan)\
**Post date:** [August 16, 2026, 11:04pm UTC](https://discuss.python.org/t/dependency-specifiers-in-and-not-in-on-version-fields/108340/2 "2026-08-16T23:04:08Z")

</div>

> [@ncoghlan](#):
>
> 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.

I’ve persuaded myself that this is the right path forward by considering the case of `"3.1" in "3.9, 3.10"`.

While that prefix matching scenario isn’t likely to come up in practice, it’s a clear reminder that the version to string fallback isn’t semantically valid for true version fields, regardless of what we had previously written in the specification.