A project manager locks your ticket-triage bot's dependencies, but the deploy image installs with pip — what does that cost?

## The shape of the failure A ticket-triage bot is developed with an all-in-one project manager. Contributors sync from the manager's lock file; the 340-case regression pack runs in CI against that environment and is green. The deployment image, written earlier and never revisited, does a plain pip install from a requirements file that a build script exports from the lock. Then the export step starts failing — the manager's version in the image moved, or the flag it used was renamed. The script wraps the export in a broad `except Exception` that logs at debug level and continues, or the build recipe ends the line with a fallback that ignores a non-zero exit. The **exception is swallowed**, the build succeeds, and the image ships with the requirements file that was already in the layer: yesterday's, or last quarter's. Nothing catches it. The regression pack passes because it never touched the image's environment. Production runs a dependency set nobody has tested, and the symptom surfaces weeks later as behaviour that cannot be reproduced locally — the reproduction environment is, by construction, the one that works. ## Why the lock file is the pivot The portability cost is not philosophical; it is that **the lock is in the manager's own format**. It is not a requirements file, pip does not parse it, and its contents are richer than a flat pinned list: per-platform and per-interpreter resolutions selected by environment markers, the dependency groups each entry belongs to, hashes, and the resolution metadata needed to re-verify rather than re-solve. An export to a requirements file is a *projection* of that. It flattens a multi-platform resolution to whatever platform the export ran on, it collapses group membership, and depending on how it is invoked it may or may not carry hashes. Even when it is perfectly correct, it is a second artifact that must be regenerated in lockstep with the first, and every derived artifact eventually drifts from its source. ## The full portability surface The deployment path is the sharpest edge, but the same fact bites in four other places. **Contributors.** Anyone touching the repository needs that manager installed, at a version compatible with the lock format. Lock formats have versions and they do change. **CI and containers.** Every job that installs dependencies now has the manager as a prerequisite, so the manager itself is an unpinned dependency unless you pin it explicitly. An unpinned installer is exactly the kind of thing that changes your build without a commit. **Downstream consumers.** If the project is a library, the lock is never published — a wheel carries the abstract `dependencies` from the `[project]` table. Your lock guarantees your builds, not your users' installs. Teams that forget this ship a library and are surprised that consumers resolve different versions. **Heterogeneous stacks.** A Python-only lock cannot express non-Python binaries, so a project that also needs system libraries or a matching accelerator runtime has a second resolution problem the lock does not cover. ## Containing it The fix that removes the class of bug, rather than the instance, is to **have one install path**. Install with the same manager inside the image, from the same committed lock, with the manager's version pinned in the image. Development, CI and production then resolve to bit-identical environments by construction, and there is no export to go stale. When an export genuinely cannot be avoided — a platform image you do not control, a policy that only allows pip, an air-gapped mirror — treat the exported file as build output with the discipline that implies: - **Fail loudly.** No broad exception handler, no ignored exit status around the export. A failed export must fail the build; that single change turns this scenario into a red pipeline instead of a silent production drift. - **Verify, do not trust.** Regenerate the export in CI and fail if it differs from the committed copy. That is a two-line check that makes staleness impossible. - **Keep the hashes.** Export with hashes and install requiring them, so a mismatch is a hard error rather than a quietly different package. - **Test what you ship.** Run at least a smoke slice of the regression pack against the *built image*, not only against the manager's environment. If the two paths must exist, the tests must cross them. The interview point underneath all of this: a lock file only guarantees reproducibility along the path that reads it. The moment a second path exists, reproducibility becomes a property you have to verify, not one you have bought.