La rama que nunca pudo ejecutarse

El ticket era preciso, y se equivocaba en la dirección que más cuesta: subestimaba el defecto.

sh0 genera un Dockerfile a partir de lo que detecta en tu repositorio. Para Python, la etapa de build instala las dependencias en /install, y la etapa de producción copia /install a /usr/local. Dos líneas de contrato, tres ramas:

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

El informe presentado, ISSUE-073, decía: la tercera rama olvida --prefix=/install. pipenv --system instala en los site-packages de la propia etapa de build; la etapa de producción copia solo /install, así que un proyecto con Pipfile publica una imagen con gunicorn y ninguna de sus propias dependencias. Build en verde, ModuleNotFoundError al arrancar el contenedor.

Diagnóstico correcto. Vuelve a leer la línea COPY.

requirements.txt<em>, pyproject.toml</em>. No hay Pipfile. El archivo que la rama comprueba nunca llegó a la etapa de build. [ -f Pipfile ] era falso en todos los despliegues que han pasado alguna vez por esta plantilla. La rama no estaba mal configurada: era inalcanzable. Nadie se había topado nunca con el fallo que describía el ticket, porque nadie había llegado nunca al código que lo habría provocado. El síntoma observable era idéntico, que es justo por lo que la causa raíz equivocada resultaba plausible.

Por qué el ticket seguía mereciendo confianza

La lección tentadora es «desconfía siempre del informe». Es falsa, y cara. ISSUE-073 se redactó a partir de una lectura de código, durante la revisión de una corrección adyacente, por alguien que encontró una violación real del contrato y la describió con fidelidad hasta donde leyó. El modo de fallo no fue el descuido: fue detenerse una línea por encima de la respuesta. La instrucción RUN es donde vive la lógica, así que ahí va el ojo. El COPY de arriba parece fontanería.

La comprobación que atrapa esta clase de defectos no cuesta nada: ante cualquier condición sobre un archivo, preguntar de dónde sale ese archivo. En un build Docker multietapa la respuesta nunca es «está ahí y ya».

La corrección, y la opción descartada

Dos cambios, aplicados a las cuatro plantillas de Python — genérica, 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

El glob recoge también Pipfile.lock. La rama convierte entonces el lock en un archivo requirements y se lo entrega al mismo pip install --prefix=/install que usan las otras dos ramas.

El otro candidato era PIP_PREFIX=/install pipenv install --deploy --system — más corto, y probablemente funciona, ya que pipenv delega en pip. Probablemente es el problema. Que pipenv reenvíe o no esa variable de entorno es un detalle de implementación de una herramienta que no controlamos; que pipenv requirements produzca un archivo requirements es comportamiento documentado. Una línea más larga, y deja de depender de algo que nadie prometió.

--deploy se descartó por el camino, y eso merece nombrarse en vez de esconderse: aborta cuando el lock está obsoleto, que es una garantía real que algunos equipos quieren. Restaurarlo es un cambio de una línea si algún usuario lo pide. Mantener en silencio un flag cuyo modo de fallo es «tu despliegue se detiene» no era una decisión que tomar en su nombre.

Qué comprueba el test

No «la cadena --prefix=/install aparece en el archivo» — aparece tres veces de todos modos, y habría pasado contra la versión rota. La aserción está acotada a la línea de la propia rama Pipfile, y verifica las dos mitades: que Pipfile* llegue a la etapa de build, y que la rama instale en el prefijo compartido. En las cuatro plantillas, porque una corrección aplicada a tres de cuatro es el mismo defecto con menor radio de impacto.

La parte que no está hecha

Todo esto se encontró leyendo código y se corrigió leyendo código. Ningún proyecto con Pipfile se ha desplegado con la plantilla corregida en una máquina real. La puerta estática está en verde — 730 tests, clippy limpio — y una puerta estática no puede decirte si pipenv requirements emite hashes que pip install luego exige en modo hash-checking. Debería. Todavía no se le ha visto hacerlo.

Por eso la reverificación en vivo es un elemento de la cola y no una casilla marcada en la release, y por eso existe este párrafo en lugar de una frase que afirme que el asunto está cerrado.