extra != '...' environment markers always evaluate to true

[geofft]

Given a wheel that has something like this in its metadata:

Requires-Dist: requests; extra != "h"
Provides-Extra: h
Requires-Dist: httpx; extra == "h"

pip will always install requests, whether or not you ask for the [h] extra.

This was mentioned in a 2020 DPO thread from @uranusjr:

The current implementation (InstallRequirement.match_markers(), which calls into packaging.markers) is to evaluate each extra against the marker separately and then combine them. So the dependencies of package[extra1,extra2] would return the union of three marker evaluations:

1. marker.evaluate({'extra': ''})
2. marker.evaluate({'extra': 'extra1'})
3. marker.evaluate({'extra': 'extra2'})

The != operator breaks this logic (all inequity operators do) since dependency; extra != 'extra1' would evaluate to true for evaluate({'extra': ''}) and evalute({'extra': 'extra2'}) and apprear as a dependency, even though extra1 is specified.

I am not aware how pip implemented this prior to PEP 508, and it might as well be that pip’s current implementation is wrong and should be fixed. I find it unlikely, however, since packaging.markers does not offer a reasonable interface to compare multiple extra values to a marker all at once.

This still seems to be the case with current pip (version 26.1.2, tested on Ubuntu 24.04).

There was some recent tightening up of the spec language in pypa/packaging.python.org#1988 which now explicitly mentions bothextra == '...' and extra != '...' as intended to work, although the purpose of the edit was to deprecate nonsensical things like extra > '...' and not so much to fix !=.

My motivation here is that onnxruntime and onnxruntime-gpu are alternatives; they both provide the same files, and whichever one is installed last wins. I want to be able to write a pyproject.toml file with

[project]
...
dependencies = [
  "onnxruntime; extra != 'gpu'",
]

[project.optional-dependencies]
gpu = [
  "onnxruntime-gpu",
]

so that installing the project with no extras gets you onnxruntime, and installing the [gpu] extra gets you only onnxruntime-gpu. However, the environment marker on onnxruntime has no effect and that package always gets installed.

(Curiously, uv has the opposite bug: extra != '...' markers always evaluate to false. I filed astral-sh/uv#20107 about that.)

[notatallshaw]

I'm taking a look at both pip and nab, this seems like a great example of writing a spec but with no clear path as to how one would implement it.

[konstin]

I'd rather remove this from the spec, clarifying that only extra == is supported.

extra != means that package could transitively remove a package from selection through activating an extra. This turns incremental resolution into a global problem: We can't state that we found a conflict when we've exhausted all versions that are currently in range, we also have to search for any package version that may activate the extra which deactivates the extra != requirement which is part of the conflict. This would be fatal to resolver complexity and performance, preventing most of the short-circuiting that makes resolving tractable.

Much weirder, with negative extras, adding a new dependency can make a previously impossible resolution solvable:

[project]
name = "foo"
version = "0.1.0"
dependencies = [
  "numpy >2",
  "numpy <2; extra != 'old-science'",
]

Only by adding a package with Requires-Dist: foo[old-science] this resolves.

[konstin]

I started a DPO thread: https://discuss.python.org/t/ban-negative-extras/108022

[notatallshaw]

I think I'm in agreement with @konstin , I'll post on the DPO thread. I don't think there's a clear path forward to implementing resolver behavior that says "don't select a requirement".

Going back to @geofft original request, wouldn't this mostly be solved if we had default extras? You could have two extras, cpu and gpu, default to cpu, but if the gpu criteria is selected it would unselect the cpu criteria. Now you would need to think about the UX if a user managed to select no or both extras, but at least the common case of a user directly selecting a package.

[geofft]

I posted a bit more on the DPO thread, but to sync here, yes, this would be solved by default extras. In particular, the semantics I want don't involve retroactively removing requirements if you start without an extra and then find it later in the dependency tree, and as I understand it that's also the semantics of PEP 771.

I was hoping it would be easier to use existing behavior in the spec (and it would avoid the question of selecting neither or both), but if getting the implementations to usefully follow the spec is of equivalent complexity to actually implementing default extras, I'm okay being told to go help default extras happen.