Mirror completion and recovery
A request can start mirroring before the copy is complete. Completion, not the first successful upload, determines a managed PyPI version's visibility.
On this page
A download triggers a version job#
An admitted public artifact GET can enqueue mirroring. The job identifies the version. The worker reads current metadata and re-evaluates current policy before copying.
For PyPI, the job covers every supported wheel and source distribution in the admitted version, plus declared metadata companions.
Partial copies do not form a complete release#
The registry can expose physical uploads one file at a time. Through Écluse, an incomplete managed PyPI version needs a validated complete public alternative or returns unavailable.
The durable state records expected identities and verified upload evidence. A duplicate-upload response alone does not prove completion.
Completion compares the current target inventory and digests with retained evidence, and verifies retained companions. It does not download every target archive again.
Completed copies can survive a public outage#
After current private authorisation and identity checks, a complete version can serve its recorded files and companions without new public admission.
Retained expected identities also guide recovery when the public source later removes a file. Do not expire those records or their referenced companions.
Direct registry access is outside this visibility guarantee and can observe partial uploads.
npm metadata has a supported subset#
The mirror retains supported installation and runtime metadata. It replaces artifact coordinates and verified hashes, and removes source-registry signatures and attestations.
Existing copies are not rewritten automatically after a metadata improvement. Consult the repair procedure before deleting and recreating a copy.