[bryangingechen]

Motivation

The dev Dockerfile copied the code in before pip install -e ., so any code change reinstalled every dependency, about 190 MB each time, and scripts/repo_check_compose.sh rebuilds the image on every run. Its base image, python:3.12-slim, wasn't pinned, so each new release of it also reran the apt-get install build-essential libpq-dev layer, another 436 MB. Over months, one machine's Docker build cache held about 15 copies of the apt layer and dozens of the pip layer.

What changes

• Dockerfile now follows Dockerfile.production:
  • the same pinned base image and uv;
  • first the packages uv.lock pins, installed into /opt/venv from pyproject.toml and uv.lock alone, with uv's download cache. /opt/venv is outside /app, which Compose mounts over;
  • then the code, then the project itself, editable, as pip install -e . installed it, so src/ stays on the path.
  • No apt-get: psycopg is psycopg[binary], and every locked package has a wheel.
• AGENTS.md says so under Containers & Volumes, and that a dependency change needs uv lock before the image builds (--locked).
• docs/sandboxed_docker_setup.md lists the images the stack now pulls.

User-visible effects

None in the app. Dev containers now get uv.lock's versions rather than the newest that pyproject.toml allows, the same as production. A pyproject.toml change without uv lock now fails docker compose build instead of resolving afresh.

Testing

• After a code change, the image rebuilds in about 2 s, with the dependency layer cached.
• In the new image, python, celery and the editable queueboard package resolve from /opt/venv, and psycopg uses its binary implementation.
• bash scripts/repo_check_compose.sh passes, skipping only step 2, the GraphQL validation, which runs on the host (core 139, syncer 543, analyzer 606, api 28, zulip_bot 350, console 96, site_analytics 81 tests).

🤖 Generated with Claude Code