feat: add lockfiles for reproducible sandbox builds

[gwarmstrong]

Summary

• Add requirements/sandbox-core.lock and requirements/sandbox.lock for pinned sandbox dependency installation
• Switch Dockerfile.sandbox from pip install to uv pip install from lockfiles for reproducible builds
• Add flask and gunicorn to requirements/code_execution.txt
• Add dependency locking instructions to Dockerfile header

Split from #1226 — this PR handles lockfile infrastructure only; gunicorn migration follows in a separate PR.

Summary by CodeRabbit

• Chores

  • Switched container build to lock-file-based dependency installation for reproducible builds, centralizing dependency installation and removing redundant build steps.
  • Added a lightweight dependency tool prior to install and reorganized image setup (WORKDIR moved earlier).
  • Conditional dependency selection by environment/architecture to reduce image size where applicable.

• New Features

  • Added flask and gunicorn to the code-execution environment.

[greptile-apps]

_{4 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Installing both lockfiles sequentially causes version conflicts. sandbox.lock includes all dependencies from code_execution.txt + stem.txt, so when both are installed, the second install downgrades packages (e.g., tqdm 4.67.3→4.66.5, markupsafe 3.0.3→2.1.5, packaging 26.0→24.1).

Should be:

Suggested change

	# Install core Python dependencies from lock file (always)
	COPY requirements/sandbox-core.lock /app/requirements-core.lock
	RUN uv pip install --system -r /app/requirements-core.lock
	# Install full dependencies including STEM libraries (skip on CI/arm64)
	COPY requirements/sandbox.lock /app/requirements.lock
	RUN if [ "$GITHUB_CI" != "1" ] && [ "$TARGETARCH" != "arm64" ]; then \
	curl -LsSf https://astral.sh/uv/install.sh | sh && \
	uv pip install --upgrade pip && \
	uv pip install -r /app/stem_requirements.txt --no-cache-dir --extra-index-url https://download.pytorch.org/whl/cpu; \
	uv pip install --system -r /app/requirements.lock --extra-index-url https://download.pytorch.org/whl/cpu; \
	fi
	# Install Python dependencies from lock file
	# - On CI/arm64: core dependencies only (sandbox-core.lock)
	# - Otherwise: full dependencies including STEM (sandbox.lock)
	COPY requirements/sandbox-core.lock /app/requirements-core.lock
	COPY requirements/sandbox.lock /app/requirements.lock
	RUN if [ "$GITHUB_CI" != "1" ] && [ "$TARGETARCH" != "arm64" ]; then \
	uv pip install --system -r /app/requirements.lock --extra-index-url https://download.pytorch.org/whl/cpu; \
	else \
	uv pip install --system -r /app/requirements-core.lock; \
	fi

[greptile-apps]

The instructions show --extra-index-url but requirements/sandbox.lock:2 doesn't include this flag in its header, despite containing CPU torch (torch==2.10.0+cpu). Update one to match the other.

[coderabbitai]

📝 Walkthrough

Walkthrough

Dockerfile.sandbox now installs Python dependencies from pre-generated lock files (sandbox-core.lock, sandbox.lock) via the uv tool and conditionally installs only core deps on CI or arm64. requirements/code_execution.txt adds flask and gunicorn.

Changes

Cohort / File(s)	Summary
Dependency Management Refactor dockerfiles/Dockerfile.sandbox	Replaced direct installs from TXT files with lock-file based installation: added uv installation, moved WORKDIR /app earlier, copied sandbox-core.lock and sandbox.lock into the image, and added conditional install (CI or arm64 → install only sandbox-core.lock, otherwise install full sandbox.lock). Removed redundant final WORKDIR /app.
Code Execution Requirements requirements/code_execution.txt	Added flask and gunicorn to the code execution requirements list (inserted between annotated-types and h5py).

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The PR title accurately summarizes the main change: adding lockfiles for reproducible sandbox builds, which is the primary objective and feature of this changeset.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch georgea/sandbox-lockfiles

---

No actionable comments were generated in the recent review. 🎉

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

🤖 Fix all issues with AI agents

In `@dockerfiles/Dockerfile.sandbox`:
- Around line 18-20: The comment about the sandbox lockfiles is misleading: it
says "always installed" for requirements/sandbox-core.lock even though the RUN
block installs only one lockfile per build; update the comment to clarify that
sandbox-core.lock contains the core dependencies (which are always satisfied
because sandbox.lock is a superset) but that the core lockfile itself may not be
installed in every build—refer to the two lockfiles by name
(requirements/sandbox-core.lock and requirements/sandbox.lock) and note that
only one lockfile is chosen during the RUN if/else logic.
- Around line 83-84: The uv install command in the Dockerfile currently pulls
the latest installer unpinned; update the RUN line that calls "curl -LsSf
https://astral.sh/uv/install.sh | sh" to pin uv to the exact version used to
generate the lockfiles (e.g., pass the installer version like 0.9.7 using the
install script's version pinning mechanism) so sandbox builds are reproducible —
replace the unpinned install invocation with the version-pinned form and ensure
the chosen version matches the lockfile generation.

[greptile-apps]

_{4 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Additional Comments (1)

dockerfiles/Dockerfile.sandbox
Build fails without python

This layer uses python -c ... (and also installs gdown with pip) even though the image doesn’t explicitly guarantee a python executable (many base images only provide python3). On systems where /usr/bin/python isn’t present, the Docker build will fail at this step. Consider switching this invocation to python3 -c ... (and install via python3 -m pip ...) to match the rest of the Dockerfile’s explicit Python 3.10 usage.

[greptile-apps]

_{4 files reviewed, no comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

_{4 files reviewed, no comments}

_{Edit Code Review Agent Settings | Greptile}