Summary

PEP 792 is now final and has a living PyPA spec.

TL;DR: PEP 792 defines "project status markers," which are project-wide states that get presented in the standard JSON and HTML indices.

For example, here's a project that's been marked as archived, meaning that it won't receive new releases:

% curl -s -H "Accept: application/vnd.pypi.simple.v1+json" https://pypi.org/simple/pepy/ |  jq '."project-status"'
{
  "status": "archived"
}

These markers are optional in the index API v1.4 and above; in earlier (<= 1.3) responses, the client should assume that all projects have the active status. Any 1.4+ response that doesn't have a status also defaults to active.

Example

PEP 792 suggests that installers produce appropriate warnings on the following statuses:

• archived: the installer should warn that the project does not expect to be updated in the future
• deprecated: the installer should warn that the project is considered obsolete by its maintainers
• quarantined: the installer should warn that the project is considered unsafe for any use (e.g. malicious). the index will prevent resolution of quarantined projects anyways, but the warning will help users understand why the resolution subsequently fails 🙂

In terms of where this should happen: I think it probably makes the most sense for these to be propagated on any environment-changing command, e.g. uv add, uv sync, uv pip install.

Subtasks:

• Data modeling + extract status markers from the detail responses (Initial PEP 792 types and index parsing #17311)
• Plumb status markers into the internal representation
  • Avoid ambiguous associated item references rkyv/rkyv#646
  • PEP 792: plumb statuses into internal representation #17631
• Plumb status markers into lockfiles? I'm not sure if this makes sense yet; they shouldn't change very often, but when they do change it could be confusing to users to have them locked.
• Propagate relevant statuses as warnings (e.g. warn users when they request a quarantined / archived / deprecated project)