James Ainslie

A package can remain useful after its maintainer stops updating it. The difficult question for a dependency consumer is whether that silence means completion, temporary absence, or the end of maintenance. Release history alone cannot answer it. PyPI now gives owners a direct way to communicate one of those states, without requiring them to remove software that existing applications still need.

The January 30 announcement introduces project archival. Owners can mark a project as archived in its settings, and its public page displays the status. Existing releases remain available for installation. The project stops accepting uploads until an owner unarchives it. PyPI explicitly says it has no plans to delete or prune distributions because their project is archived.

I dislike how much machinery Python packaging requires, but this is a useful addition to that machinery. A maintainer should be able to state that maintenance has ended without making existing dependencies disappear. The distinction gives consumers information they can use without imposing the same response on every application.

A declaration with limited consequences

An archived project signals that users should expect no further updates, including security fixes. That is a statement about future maintenance. It does not establish that an existing release contains a vulnerability, nor does it establish that the release is suitable for a new application. Those questions still depend on the code and its intended use.

The announcement recommends making a final release before archival and updating the project description with context. That is useful because a status alone cannot explain a replacement package, an architectural limitation, or the reason maintenance stopped. A final explanation can give consumers enough information to decide whether the package still fits their requirements.

There is a practical difference between declaring that work has ended and inferring it from inactivity. A library with a narrow purpose might have little reason to release often. Another library might need substantial maintenance despite a recent release. My preference is to treat explicit maintainer intent as a separate input to dependency selection. It is more informative than assigning the same meaning to every old release date.

Why archival differs from yanking

Python packaging already has a mechanism for withdrawing a problematic release from ordinary selection. PEP 592 defines yanking through metadata on download links in the Simple Repository API. Its motivating problem is a broken release that new consumers should avoid, while existing users may still need the exact artifact they selected previously.

An installer must ignore yanked releases when non-yanked versions satisfy the constraints. The proposal allows policies that preserve exact pins or existing lock-file selections, and recommends warning when an installer uses a yanked file. Warehouse presents the operation to maintainers at release level, while the repository protocol expresses it on individual files.

Archival addresses a different decision. A project can have correct releases even though nobody intends to maintain it. Treating all those releases as withdrawn would attach the wrong meaning to them. Consider a hypothetical dependency whose current release satisfies an application unchanged. Its owner ending maintenance does not itself change that release's behavior. The application still acquires a future maintenance obligation, which is a reason to plan, but that obligation is distinct from a defect in the artifact.

This distinction also matters when discussing reproducibility. Preserving access to an old artifact helps an existing installation remain possible. It does not provide the future engineering work required to keep that artifact compatible or secure. Archival lets those two concerns remain visible separately.

Quarantine supplied the implementation

The implementation builds on PyPI's project lifecycle model. The December explanation of quarantine describes the earlier problem. Administrators responding to potentially malicious projects needed an alternative to complete removal, which was disruptive and difficult to reverse. Quarantine removes a project from normal installation visibility while retaining an administrative path to investigate and restore it.

That work introduced LifecycleStatus on the project model. Decisions about project state could then use one explicit representation, with transitions that preserve the possibility of reversal. The December account already identified archival as a possible extension. The January change uses that existing mechanism for an owner-controlled maintenance declaration.

Shared implementation does not imply identical permissions or effects. Quarantine is an administrative containment action. Archival is a declaration owners make about their own project, and archived packages remain installable. Keeping those meanings distinct is necessary for consumers interpreting the status. An archived dependency is not a malware finding.

The remaining installer gap

The implementation account from Trail of Bits identifies an immediate limitation. Archival is recorded and displayed in the web interface, but installers cannot yet use it to alert developers through a machine-readable status interface. The announcement describes public API changes as further work. It does not claim that an ordinary installation now warns about archival.

That gap limits how much this release changes automated dependency handling. A developer inspecting the project page can see the declaration. A policy that needs to reject archived dependencies requires information that the new web display alone does not supply to an installer. Presenting the status and specifying its protocol representation are separate pieces of work.

Trail of Bits also explains why additional statuses need discussion. A project may be complete and unmaintained at the same time, while abandoned and unmaintained can overlap. Those labels do not form an obvious set of mutually exclusive states. Archival provides a comparatively clear initial meaning. Future status definitions will need equally clear consequences for the people and tools that consume them.