The night before a library Wi-Fi automation change window, a city build pulls a new major of a shared HTTP client because dependencies floated on latest. Which practice would have kept the build reproducible?
Select an answer to reveal the explanation.
Short Explanation
Floating latest is like ordering 'whatever soup is popular today' the night of a banquet—surprises arrive. Exact pins or a lockfile freeze the recipe so the same build shows up for the change window.
Full Explanation
Reproducible builds for a library Wi-Fi automation change window require that dependency resolution be deterministic. Pinning exact versions or committing a lockfile freezes the resolved graph so the shared HTTP client (and every transitive package) resolves the same way on every runner. That prevents a surprise major upgrade the night before the window simply because a floating “latest” tag moved.
Deleting the virtualenv and reinstalling from an unpinned lower bound every deploy reintroduces float on each install and maximizes surprise. Preferring newest prerelease tags intentionally destabilizes the graph and is the opposite of change-window hygiene. Vendoring transitive packages into Git LFS without recording versions stores blobs without a reproducible resolution record, so two engineers can still disagree on which unofficial tree they copied.
Exam caveat: a lower-bound constraint in a requirements file is not the same as a lock—without a lockfile or exact pins, “compatible with X” can still pull a new major overnight. Operational check: after dependency changes, regenerate or verify the lockfile in CI on a clean runner, diff the resolved HTTP client version against the last known-good build, and only then promote the library Wi-Fi automation artifact.