← Components

Python pins

Dependencies and runtimes · dependency lock. On a deployment this row is a control; the demo shows the row with the reading its source supports.

Evidence

Running

91 pins, hash-checked; 25 direct in requirements.txt

Built

91 pins, lock dated 2026-08-21

Latest known

no advisory against any pin (checked 3 days ago)

Source

requirements.lock

Checked

3 days ago

Cadence

every 14 days

Mode

record only

State

current

Backup unit

The previous image.

Recovery

The previous image.

The five steps

Plan, back up, apply, verify, recover — in record only mode. On a deployment each step runs, is verified and lands on the audit trail; every component on the demo is current, so every step reads done.

1. ✓ done Plan The lock's pins are compared with the set installed inside the image and with the advisory manifest; the plan names every pin that changes and the image release that carries it.
2. ✓ done Back up The previous image digest stays kept; nothing is pip-installed into a running container, ever.
3. ✓ done Apply Regenerate requirements.lock on the workstation, build and sign the release image, and ship it through the Running image row.
4. ✓ done Verify The installed set inside the new image equals the lock, and the advisory manifest lists nothing against it.
5. ✓ done Recover Run the previous image; the pins roll back with it.

Every row behind this reading (91)

History

Applies and recoveries of this row, from the update journal. On a deployment every apply and every recovery lands here as it completes.

No apply or recovery recorded for this row. The demo's journal holds one completed update, of Running image.

Acknowledge: keep as is until <date> because <reason> — on a deployment this line is a form, audited as system.component_acknowledged; the demo shows the words.

← Back to Components