The Branch That Could Never Fire

The ticket was precise, and it was wrong in the direction that costs the most: it understated the defect.

sh0 generates a Dockerfile from whatever it detects in your repository. For Python, the builder stage installs dependencies into /install, and the production stage copies /install into /usr/local. Two lines of contract, three branches:

dockerfileCOPY requirements.txt* pyproject.toml* ./
RUN if [ -f requirements.txt ]; then pip install --prefix=/install -r requirements.txt; \
    elif [ -f pyproject.toml ]; then pip install --prefix=/install .; \
    elif [ -f Pipfile ]; then pip install pipenv && pipenv install --deploy --system; fi

The filed issue, ISSUE-073, said: the third branch forgets --prefix=/install. pipenv --system installs into the builder's own site-packages, the production stage copies only /install, so a Pipfile project ships an image with gunicorn and none of its own dependencies. Green build, ModuleNotFoundError at container start.

Correct diagnosis. Read the COPY line again.

requirements.txt<em>, pyproject.toml</em>. No Pipfile. The file the branch tests for never arrived in the build stage. [ -f Pipfile ] was false on every deploy that has ever run through this template. The branch was not misconfigured — it was unreachable. Nobody had ever hit the bug the ticket described, because nobody had ever reached the code that would cause it. The observable symptom was identical, which is exactly why the wrong root cause was plausible.

Why the ticket was still worth trusting

The tempting lesson is "always distrust the report." That's wrong, and expensive. ISSUE-073 was filed from a code read during review of an adjacent fix, by someone who found a real contract violation and described it accurately as far as they read. The failure mode wasn't carelessness; it was stopping one line above the answer. The RUN instruction is where the logic lives, so the eye goes there. The COPY above it looks like plumbing.

The check that catches this class costs nothing: for any conditional on a file, ask where that file comes from. In a multi-stage Docker build the answer is never "it's just there."

The fix, and the option not taken

Two changes, applied to all four Python templates — generic, Django, FastAPI, Flask:

dockerfileCOPY requirements.txt* pyproject.toml* Pipfile* ./
...
elif [ -f Pipfile ]; then pip install pipenv && \
  if [ ! -f Pipfile.lock ]; then pipenv lock; fi && \
  pipenv requirements > /tmp/pipenv-req.txt && \
  pip install --prefix=/install -r /tmp/pipenv-req.txt; fi

The glob picks up Pipfile.lock too. The branch then converts the lock to a requirements file and hands it to the same pip install --prefix=/install the other two branches use.

The other candidate was PIP_PREFIX=/install pipenv install --deploy --system — shorter, and it probably works, since pipenv shells out to pip. Probably is the problem. Whether pipenv forwards that environment variable is an implementation detail of a tool we don't control; pipenv requirements producing a requirements file is documented behaviour. One line longer, and it stops depending on something nobody promised.

--deploy was dropped in the process, and that deserves naming rather than hiding: it aborts when the lock is stale, which is a real guarantee some teams want. Restoring it is a one-line change if a user asks. Silently keeping a flag whose failure mode is "your deploy stops" wasn't the call to make on their behalf.

What the test asserts

Not "the string --prefix=/install appears in the file" — it appears three times regardless, and would have passed against the broken version. The assertion is scoped to the Pipfile branch line itself, and it checks both halves: that Pipfile* reaches the builder, and that the branch installs into the shared prefix. Across all four templates, because a fix applied to three of four is the same defect with a smaller blast radius.

The part that isn't done

This was found by reading code and fixed by reading code. No Pipfile project has been deployed through the corrected template on a real box. The static gate is green — 730 tests, clippy clean — and a static gate cannot tell you whether pipenv requirements emits hashes that pip install then enforces in hash-checking mode. It should. It hasn't been watched doing it.

That's why the live re-verify is a queue item and not a checkbox in the release, and why this paragraph exists instead of a sentence claiming the issue is closed.