Short answer: we verified a starter nest by restoring it on the same machine that packed it, and everything passed. A clean machine then failed to install its dependencies, because the dependency list had been exported from the operating system's own Python and half of it was OS furniture no clean machine can install. Verifying on the packing machine proves the files come back; it cannot prove the dependencies can be rebuilt anywhere else.
This happened on 2026-08-10, on the fourth build of our first starter nest.
What happened
The dependency lock had 206 entries. One of them, PyGObject, pulls in pycairo. On the machine we tested, that was invisible — it was already installed. On a clean machine, pycairo has no prebuilt package for that setup, so the installer tried to compile it from source, and compiling it needs the cairo development libraries a clean machine doesn't have. The restore stopped at the dependency step.
Why were those entries there at all? The lock had been exported from the machine image's system Python — the interpreter the cloud image ships inside the OS. That interpreter carries the distribution's own packages (PyGObject, dbus-python, distro) and a whole Jupyter stack the image happens to include. None of it belonged to the workflow. The export faithfully recorded one machine's furniture and called it a requirement.
Why our check didn't catch it
We did verify a rebuild. Every file came back and matched its checksum, the app started, the image regenerated.
But that rebuild ran on the machine that did the packing. Its system Python already had every one of those packages, so the rebuilt environment quietly borrowed them. The green result was real; it answered a different question. It showed that the files come back as stored. It did not show that the dependencies can be installed somewhere else.
The more convenient the "machine that already has everything" is, the more certain it is that the test can never fail on the thing that will break for a stranger.
The fix, in numbers
We exported the lock again from an isolated environment containing only what the workflow installed. The lock went from 206 entries to 103 — every removed entry was image furniture. (Same workflow, same machine class, only the export changed; it doesn't mean every lock halves.)
Then we ran the test we should have run first: a restore on a machine with nothing on it. The fifth build went through end to end in 163.8 seconds on 2026-08-10 — machine check, download of the 12.45 GB nest, a checksum check of every file, and a from-scratch dependency install (66.1 s of that). One machine, one run, local disk; it shows this nest now installs where nothing pre-exists, and nothing more general.
What the tool does about it now
- Packing names the problem. When a dependency list contains packages that only an operating system's own Python could have,
renest packsays so, lists them, and explains how to pack from a virtual environment instead. It still writes the archive — it is a faithful record of that machine — but marks the nest as not rebuildable on other machines, and a hand-off of such a nest is refused. - Restoring checks before the big download. A restore tests whether the dependency list can be installed on this machine before any model files move, so the failure costs seconds instead of a 12 GB download.
The one-line version: a rebuild check needs a machine that has nothing on it.