Support for PEP 792

[woodruffw]

What's the problem this feature will solve?

Hello pip maintainers!

TL;DR: I think it'd be great if pip supported PEP 792, which is now final (with a canonical copy). PEP 792 defines standard "project status markers," which are presented as part of index API responses in API versions 1.4 and above. Package installers and other index consumption tools can use these status markers to inform/warn users, e.g. when a project is marked as deprecated (or quarantined, in which case the installation will fail shortly anyways due to no dists being offered).

In terms of problems solved:

1. Status markers give package downstreams (dependents) a high-quality signal about whether a package might need to be replaced or removed, eliminating the need for heuristics that are currently typically applied (like looking at the project's source repo activity).
2. Specifically in the quarantined case: status markers make it easier for installers like pip to contextualize any errors the user is about to see due to resolution failure (as quarantine means that the index responds with an empty dist listing).

Describe the solution you'd like

On pip install, I think pip should emit warnings when it encounters a project in the archived, quarantined, or deprecated state. The appropriate kind of warning to emit is suggested under each state's "installer semantics" in the spec.

(This could probably be done in a manner that minimizes the risk of warning spam, e.g. collecting all statuses and summarizing them only at the end of the pip install.)

Alternative Solutions

One alternative solution would be for pip to not implement this PEP, since the semantics are entirely optional for the installer 🙂. However, I think users would benefit from having project statuses presented to them.

Additional context

I've opened a similar feature request with uv here: astral-sh/uv#15254

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[pfmoore]

In principle I don't have a problem with this, although I'm concerned that we don't present users with warnings that they can't do anything about¹, such as "you are installing X, which is deprecated" when X is some deep dependency of what the user is actually installing. Maybe we should restrict these warnings to only top-level requirements?

Conversely, maybe build backends should be checking declared dependencies and warning if any are deprecated/quarantined? Otherwise, no-one will ever see warnings for transitive dependencies.

Footnotes

1. Something I object strongly to, when it happens to me as a user. ↩

[woodruffw]

Maybe we should restrict these warnings to only top-level requirements?

That makes sense to me, and agreed about it being annoying when non-actionable information about dependencies is presented. However, even that is nuanced: I might have a dep relation like:

mypkg
|
\
 foobar[widgets]
 |
 \
  widgets

...where widgets is deprecated (or whatever) and is transitive, but only because I explicitly requested the [widgets] extra from foobar. In that case I'd like to be warned (because I might be able to remove the extra), but I'm not sure if the current resolver has the "taint" information needed to distinguish that from cases where I don't control the transitive deps.

That being said, I think a "good enough" solution would be to only flag top-level dependencies (by default), and from there allow users to opt into the check for all dependencies. I'm curious what your thoughts are on that 🙂

[pfmoore]

I have no strong opinions on anything that's opt-in (I can simply not opt in). As long as the default behaviour only ever produces warnings the user can fix, I'm happy 🙂

only because I explicitly requested the [widgets] extra from foobar

Who is "I" in this sentence? The user is installing mypkg, and I assume can't modify the dependencies of mypkg. So the user isn't able to remove the extra, hence can't address the warning. Are you assuming the user is the developer of mypkg, and can modify that package and reinstall? Because that's not the scenario I'm concerned about.

[woodruffw]

Are you assuming the user is the developer of mypkg, and can modify that package and reinstall? Because that's not the scenario I'm concerned about.

Yeah, I was envisioning myself as the developer of mypkg, with a dependency on foobar[widgets]. In that case I'd have a transitive dependency on widgets via foobar, but that transitive dep is also one I fully control (since it opted into it via the extra).

So this would be a case where I (as mypkg maintainer) can fix the dependency, but we wouldn't flag it because pip would (presumably) only see it as a transitive dep.

(Maybe the answer here is that this is an edge case scenario, and therefore not worth over-weighting?)