claude-bot
598f7fd662
Replaces the previous tree entirely. The pipeline is four separable pieces, each
testable on its own:
1. leanbench/llm.py provider-neutral OpenAI-compatible connector, stdlib only,
with retries, JSON coercion and a scripted client so the
rest of the code is testable without a network.
2. leanbench/detect.py per-page detection of formalizable mathematics. Case 1 is
mathematics asserted as fact (definition/theorem/lemma/...,
deliberately not sub-classified); case 2 is a problem left
open to the reader. Hits come back as spans -- start page
and index, end page and index -- so several per page is
normal. A hit cut off by the page end makes the detector
re-read that page together with the next, repeatedly, so an
item spread over three pages is found whole.
Offsets come from verbatim quotes resolved by
leanbench/anchors.py (exact -> whitespace-insensitive ->
fuzzy), because models quote well and count badly.
3. leanbench/formalize.py + leanbench/verify.py
each span becomes one Lean 4 declaration, judged by the real
compiler: full elaboration for case 1, statement legality
only for case 2, which has no proof to check. Lean's own
diagnostics feed back for a repair attempt. "verified" (Lean
accepted it) and "proved" (accepted with no sorry) are kept
strictly apart.
4. leanbench/db.py indexed SQLite plus JSONL export. Every item is indexed by
the types of its inputs, or by its own type when it is not a
proof, and records the source book (sha256) and the page it
starts on -- so `drop --source H --pages A-B` followed by a
re-ingest redoes exactly those pages and nothing else.
Infrastructure:
- lean/ Lake project pinned to Mathlib.
- docker/ image carrying Lean 4 and a prebuilt Mathlib. The Mathlib
revision and the toolchain are resolved against each other at
build time rather than both hardcoded, so the build does not rot.
One Docker layer per Lean step, each long one under `timeout`:
the gigabyte cache fetch earns a layer that a later failure never
invalidates, and a stalled step fails with a message instead of
sitting silent for an hour. There is deliberately no `lake build`
of our own library -- verification runs `lake env lean` against
Mathlib's oleans and needs nothing else, and building the library
was pure cost. docker/smoke.py runs the whole pipeline inside the
image against the real compiler, with the LLM scripted.
- .gitea/workflows ci (lint + tests in a venv, since the runner image's Python is
Debian-managed and refuses installs into itself), docker (build,
verify, optionally push), ingest (submit a book by hand). The
docker build runs with --progress=plain, because BuildKit's
default renderer collapses a long step into one rewritten line
and a stall then looks exactly like progress.
The docker workflow is not a throwaway build: it leaves the image, the layer cache,
an idle `lean-bench` container and the `lean-bench-data` / `lean-bench-books`
volumes in place on the runner, and never prunes, so the environment is there to be
used afterwards. Pushing to the registry is optional and cannot fail the build --
Gitea's container registry does not accept the built-in Actions token, so that needs
a REGISTRY_TOKEN secret with write:package.
58 tests; they need neither network nor Lean.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ci5T3gWDhhmqDec3e1XtYZ
94 lines
4.1 KiB
Docker
94 lines
4.1 KiB
Docker
# lean-bench: Lean 4 + Mathlib + the ingestion pipeline, in one image.
|
|
#
|
|
# Build from the repository root:
|
|
# docker build -f docker/Dockerfile -t lean-bench:latest .
|
|
#
|
|
# The Mathlib revision and the Lean toolchain are resolved against each other at
|
|
# build time (see docker/resolve-mathlib.sh); override with --build-arg MATHLIB_REV=v4.33.0.
|
|
FROM ubuntu:24.04
|
|
|
|
LABEL org.opencontainers.image.title="lean-bench" \
|
|
org.opencontainers.image.description="Detect formalizable mathematics in books and turn it into verified, indexed Lean 4" \
|
|
org.opencontainers.image.source="https://gitea.entroia.com/Zayden-Jung/lean-bench"
|
|
|
|
ENV DEBIAN_FRONTEND=noninteractive \
|
|
ELAN_HOME=/opt/elan \
|
|
PATH=/opt/elan/bin:$PATH \
|
|
PYTHONUNBUFFERED=1
|
|
|
|
RUN apt-get update && apt-get install -y --no-install-recommends \
|
|
build-essential ca-certificates curl git jq sqlite3 \
|
|
libgmp-dev python3 python3-pip \
|
|
&& rm -rf /var/lib/apt/lists/*
|
|
|
|
# -- elan (the Lean toolchain manager) --------------------------------------
|
|
RUN curl -fsSL https://raw.githubusercontent.com/leanprover/elan/master/elan-init.sh -o /tmp/elan-init.sh \
|
|
&& sh /tmp/elan-init.sh -y --no-modify-path --default-toolchain none \
|
|
&& rm /tmp/elan-init.sh \
|
|
&& elan --version
|
|
|
|
WORKDIR /opt/lean-bench
|
|
|
|
# -- Lean project: toolchain, Mathlib, and its prebuilt cache ---------------
|
|
# One layer per step on purpose. The cache fetch is the expensive one (gigabytes),
|
|
# so it gets a layer of its own: a failure in any later step re-runs that step, never
|
|
# the download. Every long step is wrapped in `timeout` so a stall fails loudly with
|
|
# a diagnosable message instead of hanging until the CI job's own limit.
|
|
ARG MATHLIB_REV=auto
|
|
COPY lean/ lean/
|
|
COPY docker/resolve-mathlib.sh docker/resolve-mathlib.sh
|
|
RUN chmod +x docker/resolve-mathlib.sh && docker/resolve-mathlib.sh lean "$MATHLIB_REV"
|
|
|
|
RUN elan toolchain install "$(cat lean/lean-toolchain)" \
|
|
&& elan default "$(cat lean/lean-toolchain)"
|
|
|
|
# Resolve dependencies: clones Mathlib and writes the manifest.
|
|
RUN cd lean && timeout 1800 lake update
|
|
|
|
# Mathlib's prebuilt artifacts. Slow, large, and cached as its own layer.
|
|
RUN cd lean && timeout 5400 lake exe cache get
|
|
|
|
# The honest check that this image can do its job, and it is exactly what
|
|
# verification does at runtime: elaborate a file against Mathlib with `lake env lean`.
|
|
# There is deliberately no `lake build` here -- compiling our own library is something
|
|
# nothing in the pipeline ever uses.
|
|
#
|
|
# Loading Mathlib's environment needs several GB of RAM. On a host that does not have
|
|
# it, this does not fail: it thrashes, and the only symptom is silence. So it runs
|
|
# under `timeout`, and exit 124 is reported for what it almost always is.
|
|
RUN cd lean && timeout 1200 lake env lean LeanBench.lean; status=$?; \
|
|
if [ "$status" -eq 124 ]; then \
|
|
echo "ERROR: elaborating 'import Mathlib' timed out after 20 minutes." >&2; \
|
|
echo "Every olean it needs is already on local disk, so this is not the network." >&2; \
|
|
echo "Loading Mathlib wants ~4-8 GB of RAM. This machine has:" >&2; \
|
|
{ free -h || head -3 /proc/meminfo; } >&2 2>/dev/null; \
|
|
echo "Give the build host more memory, or build this image elsewhere." >&2; \
|
|
fi; \
|
|
[ "$status" -eq 0 ] || exit "$status"; \
|
|
lake env lean --version
|
|
|
|
# -- the pipeline -----------------------------------------------------------
|
|
COPY pyproject.toml README.md ./
|
|
COPY leanbench/ leanbench/
|
|
RUN pip install --break-system-packages --no-cache-dir . \
|
|
&& lean-bench --help > /dev/null
|
|
|
|
COPY docker/entrypoint.sh /usr/local/bin/leanbench-entrypoint
|
|
RUN chmod +x /usr/local/bin/leanbench-entrypoint
|
|
|
|
ENV LEANBENCH_LEAN_PROJECT=/opt/lean-bench/lean \
|
|
LEANBENCH_LEAN_COMMAND='["lake","env","lean"]' \
|
|
LEANBENCH_DATABASE=/data/leanbench.sqlite \
|
|
LEANBENCH_LLM_MODEL=qwen-max \
|
|
LEANBENCH_LLM_BASE_URL=https://dashscope.aliyuncs.com/compatible-mode/v1 \
|
|
LEANBENCH_LLM_API_KEY_ENV=DASHSCOPE_API_KEY
|
|
|
|
# /books is where you put the source you are submitting; /data holds the database.
|
|
VOLUME ["/data", "/books"]
|
|
WORKDIR /work
|
|
|
|
RUN mkdir -p /work
|
|
|
|
ENTRYPOINT ["leanbench-entrypoint"]
|
|
CMD ["doctor"]
|