Pipenv: Pipenv que ya no funciona en el directorio raíz no figura como un cambio importante

Creado en 28 may. 2020  ·  27Comentarios  ·  Fuente: pypa/pipenv

Descripcion del problema

Nuestras compilaciones de Docker fallaron esta mañana debido a un cambio en el comportamiento al ejecutar pipenv install en el directorio raíz.
Cuando se ejecuta con la última versión (2020.5.28), se genera un error después de que se crean e instalan las dependencias ERROR: Pipenv is not intended to work under the root directory, please choose another path.
Parece que este es un cambio introducido en # 3386, relacionado con un problema planteado en # 3434.
Este problema es realmente solo para señalar que este cambio de comportamiento debe aparecer como interrumpido en el registro de cambios, ya que actualmente no parece que se mencione.
Por el momento, hemos solucionado esto fijando pipenv en la última versión (2018.11.26).

Resultado Esperado

N / A

Resultado actual

N / A

Pasos para replicar

N / A

Type Regression

Comentario más útil

Puedo confirmar que este comportamiento no ocurre en la versión 2018.11.26 .

@mohamedMok Puedes usar pip install 'pipenv==2018.11.26' que es la última versión que no tiene este cambio importante.

Todos 27 comentarios

hola @ gps035 ,

Tengo el mismo problema con pipenv.
¿Podría mostrar cómo ha fijado la versión pipenv ?

Gracias

Puedo confirmar que este comportamiento no ocurre en la versión 2018.11.26 .

@mohamedMok Puedes usar pip install 'pipenv==2018.11.26' que es la última versión que no tiene este cambio importante.

@ gps035 ¿ Alguna posibilidad de enviar un PR para mencionarlo en el CHANGELOG?

He presentado un PR para abordar este problema, gracias a todos.

No es un cambio de ruptura divertido, todos nuestros dockers están usando pipenv install durante la compilación: /

Me encontré con el mismo problema, usando la solución en https://github.com/pypa/pipenv/issues/4273#issuecomment -635303079 funcionó para mí.

Nuestras compilaciones de Docker fallaron esta mañana debido a un cambio en el comportamiento al ejecutar pipenv install en el directorio raíz.

¿Puede explicar el flujo de trabajo aquí? ¿Está usando --system ?

Como acabo de mencionar en el n. ° 4275:

La razón principal del cambio en primer lugar se debe a la ubicación de entornos virtuales y rutas de Python relacionadas; hasta donde yo sabía, esta fue una causa sustancial de errores y roturas y básicamente no funcionó. El hecho de que está rompiendo los flujos de trabajo es lo primero que escucho de que funciona .

Esto no pretende ser un cambio importante, está destinado a evitar una interacción previamente rota; para cualquier persona para quien esto estuviera funcionando, incluya el conjunto completo de argumentos de línea de comando que estaba pasando a pipenv (por ejemplo, pipenv install --<whatever> e información sobre su flujo de trabajo:

  • estabas usando Docker? alguna otra infraestructura de contenedores?
  • ¿Qué usuario estaba invocando el comando? qué UID (básicamente, era una cuenta raíz)
  • ¿Estaba pasando --system a pipenv, creando su propio virtualenv o permitiendo que pipenv creara uno para usted?
  • ¿En qué sistema operativo se estaba ejecutando pipenv?
  • ¿Qué versión de Python?

Probablemente sea suficiente por ahora

@techalchemy Estas son las partes relevantes de nuestro Dockerfile que ya no funciona.

FROM python:3.8

RUN pip install --no-cache-dir pipenv
RUN pipenv install --system --deploy

@techalchemy Gracias por

  • Escenario de contenedorización: sí, aunque no estrictamente Docker (imágenes OCI)
  • Pipenv se ejecuta dentro del entorno de construcción del contenedor como uid = 0
  • La bandera --system no se pasa
  • Linux
  • Python 3.8

En caso de que sea útil para investigar o reproducir el problema, los pasos de compilación están visibles en este objetivo de Make .

Para cualquiera que quiera usar el último pipenv con --system , adaptar su Dockerfile configurando un WORKDIR y copiando su Pipfile / lockfile en él de la siguiente manera puede ser útil:

WORKDIR /code
COPY Pipfile Pipfile.lock /code/
RUN pip install pipenv && pipenv install --system
COPY . /code/
  • construyendo dockerfile
  • raíz
  • ver código a continuación
  • python:3-slim imagen acoplable, viene con Debian GNU/Linux 10
  • 3.8
FROM python:3-slim AS base

ENV PYROOT /pyroot
ENV PYTHONUSERBASE $PYROOT
ENV PATH $PATH:$PYROOT/bin

FROM base AS builder
RUN pip install pipenv
COPY Pipfile* ./
RUN PIP_USER=1 PIP_IGNORE_INSTALLED=1 pipenv install --system --deploy --ignore-pipfile

Para cualquiera que quiera usar el último pipenv con --system , adaptar su Dockerfile configurando un WORKDIR y copiando su Pipfile / lockfile en él de la siguiente manera puede ser útil:

WORKDIR /code
COPY Pipfile Pipfile.lock /code/
RUN pip install pipenv && pipenv install --system
COPY . /code/

Esto funcionó para mí. Solo recuerde crear el directorio /code antes.

Esto funcionó para mí. Solo recuerde crear el directorio /code antes.

el comando WORKDIR ya crea el directorio si no existe

Usar WORKDIR no me funcionó. Estoy recibiendo un error

Step 9/9 : RUN PIP_USER=1 PIP_IGNORE_INSTALLED=1 pipenv install --system --deploy --ignore-pipfile
 ---> Running in da6fa387210f
Installing dependencies from Pipfile.lock (387af5)…
Failed to load paths: /bin/sh: 1: /root/.local/share/virtualenvs/build-5NmaZ4l5/bin/python: not found

Output: 
Failed to load paths: /bin/sh: 1: /root/.local/share/virtualenvs/build-5NmaZ4l5/bin/python: not found

Output: 
Failed to load paths: /bin/sh: 1: /root/.local/share/virtualenvs/build-5NmaZ4l5/bin/python: not found

Output: 
^Cmake: *** [build-image-base] Interrupt: 2

al usar dockerfile a continuación

FROM python:3-slim AS base

ENV PYROOT /pyroot
ENV PYTHONUSERBASE $PYROOT
ENV PATH $PATH:$PYROOT/bin

FROM base AS builder
WORKDIR /build
RUN pip install pipenv
COPY Pipfile* /build/
RUN PIP_USER=1 PIP_IGNORE_INSTALLED=1 pipenv install --system --deploy --ignore-pipfile

esto no parece ser realmente un error de compilación, vea # 4220

Como nota al margen, pipenv desarma $PIP_USER y no estoy relativamente seguro de cómo interactúa $PYTHONUSERBASE con él.

Además, la bandera --deploy sería algo inútil con la bandera --ignore-pipfile - --deploy se utiliza para garantizar que su Pipfile y su Pipfile.lock están alineados, es decir, que su Pipfile.lock se generó a partir del Pipfile . Si indica que desea ignorar su pipfile, esta verificación nunca ocurre.

En cualquier caso @killuazhu, el error en los registros que incluyó posiblemente esté relacionado con las manipulaciones de su ruta de Python, pero requerirá más investigación si puede presentar un problema por separado

Como referencia, el problema original de # 3434 ocurre cuando uno intenta pipenv install debajo de / sin un Pipfile. Y la configuración en este ticket es pipenv install debajo de / con un Pipfile, que solía estar funcionando en 2018.11.26. Sin embargo, # 3386 eligió un enfoque de resolución incorrecto, que evita el uso del directorio raíz por completo.

Gracias por arreglarlo, ¿tiene una ETA sobre cuándo se incluirá el arreglo en una nueva versión del paquete pypi?

Necesitamos asegurarnos de que todos los problemas de regresión se solucionen y la nueva versión saldrá la próxima semana.

¡Increíble gracias, lo agradezco!

Puedo confirmar que este comportamiento no ocurre en la versión 2018.11.26 .

@mohamedMok Puedes usar pip install 'pipenv==2018.11.26' que es la última versión que no tiene este cambio importante.

Recibía un error ligeramente diferente al ejecutar python3 -m pipenv install --three --system

Output:
Failed to load paths: /bin/sh: 1: /root/.local/share/virtualenvs/app-4PlAip0Q/bin/python: not found

Anclar a la versión anterior también funcionó para mí. ¡Gracias!

Puedo confirmar que este comportamiento no ocurre en la versión 2018.11.26 .
@mohamedMok Puedes usar pip install 'pipenv==2018.11.26' que es la última versión que no tiene este cambio importante.

Recibía un error ligeramente diferente al ejecutar python3 -m pipenv install --three --system

Output:
Failed to load paths: /bin/sh: 1: /root/.local/share/virtualenvs/app-4PlAip0Q/bin/python: not found

Anclar a la versión anterior también funcionó para mí. ¡Gracias!

Tengo el mismo problema. Ahora anclar a la versión anterior como solución

Necesitamos asegurarnos de que todos los problemas de regresión se solucionen y la nueva versión saldrá la próxima semana.

Este problema todavía está presente en la versión 2020.6.2:

Salida:
No se pudieron cargar las rutas: / bin / sh: 1: /root/.local/share/virtualenvs/app-lp47FrbD/bin/python: no encontrado

¿Podría confirmar si se esperaba que este problema se solucionara en la versión 2020.6.2?

Puedo confirmar que estoy resolviendo este problema con lo siguiente Dockerfile

FROM python:3.7-slim

ENV LC_ALL C.UTF-8
ENV DEBIAN_FRONTEND noninteractive

RUN apt-get update && \
    apt-get upgrade && \
    apt-get install -y --no-install-recommends libldap2-dev libsasl2-dev libssl-dev && \
    apt-get clean autoclean && rm -rf /var/lib/apt/* /var/cache/apt/* && \
    apt-get autoremove --purge && \
    pip install pipenv --no-cache-dir

WORKDIR /app

COPY Pipfile Pipfile.lock ./
RUN pipenv install --deploy --system --verbose

ENTRYPOINT ["uvicorn", "web.main:app", "--host", "0.0.0.0"]

EXPOSE 8000/tcp

@frostming ¿Puede volver a abrir el problema?

También puedo confirmar que estoy resolviendo este problema con el siguiente Dockerfile:

FROM python:3.7.6-slim-stretch
ENV PYTHONDONTWRITEBYTECODE 1
ENV PYTHONUNBUFFERED 1
WORKDIR /app
COPY .  /app
RUN pip install --upgrade pip
RUN pip install pipenv
RUN pipenv install --system --deploy --ignore-pipfile
CMD ["/bin/bash", "scripts/entrypoint.sh"]

Aquí está el error:

Step 10/11 : RUN pipenv install --system --deploy --ignore-pipfile
 ---> Running in 00386bcedd89
Installing dependencies from Pipfile.lock (d14b54)…
Failed to load paths: /bin/sh: 1: /root/.local/share/virtualenvs/app-4PlAip0Q/bin/python: not found

Output: 
Failed to load paths: /bin/sh: 1: /root/.local/share/virtualenvs/app-4PlAip0Q/bin/python: not found

Output: 
Failed to load paths: /bin/sh: 1: /root/.local/share/virtualenvs/app-4PlAip0Q/bin/python: not found

Para las personas que aún tienen este problema, la solución más fácil es configurar su Dockerfile como:

FROM python:3.7-slim

# Set environment varibles
ENV PYTHONDONTWRITEBYTECODE 1
ENV PYTHONUNBUFFERED 1

# Set work directory
WORKDIR /code


# Install dependencies
COPY Pipfile Pipfile.lock /code/
RUN pip install pipenv==2018.11.26 && pipenv install --system             # <- this is the fix
...
¿Fue útil esta página
0 / 5 - 0 calificaciones