pyproject.toml uses range pins (>=) for all dependencies; without a
lockfile, a fresh `pip install .` on a different day could pull
materially different versions of fastapi, sqlalchemy, httpx, etc.
For a production-shaped service that's a reproducibility risk —
especially since we don't run a CI pipeline that would catch
"works on yesterday's container, fails on today's."
requirements.lock pins every transitive dep (60 packages) to the
exact versions running in the test container today. Dockerfile is
updated so both stages install from the lockfile first, then install
the project itself with --no-deps:
pip install -r requirements.lock
pip install --no-deps .
That way pyproject.toml's range pins document our compatible
upper-and-lower bounds, but the lockfile is what actually gets
installed on every build.
To bump deps later: bump pyproject.toml ranges, rebuild a fresh
venv, `pip freeze` it, save back to requirements.lock.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
