Pipenv: Pipenv ne fonctionnant plus sous le répertoire racine n'est pas répertorié comme un changement de rupture

salut @ gps035 ,

J'ai le même problème avec pipenv.
Pouvez-vous nous montrer comment vous avez épinglé la version pipenv ?

Merci

Je peux confirmer que ce comportement ne se produit pas sur la version 2018.11.26 .

@mohamedMok Vous pouvez utiliser pip install 'pipenv==2018.11.26' qui est la dernière version qui n'a pas ce changement de rupture.

@ gps035 Une chance d'envoyer un PR pour le mentionner dans le CHANGELOG?

J'ai déposé un PR pour résoudre ce problème, merci à tous.

Pas un changement de rupture amusant, tous nos dockers utilisent l'installation de pipenv pendant la construction: /

Rencontrez le même problème, en utilisant le correctif de https://github.com/pypa/pipenv/issues/4273#issuecomment -635303079 a fonctionné pour moi.

Nos builds de docker ont échoué ce matin en raison d'un changement de comportement lors de l'exécution de pipenv install dans le répertoire racine.

pouvez-vous expliquer le flux de travail ici - utilisez-vous --system ?

Comme je viens de le mentionner dans # 4275:

La raison principale du changement est en premier lieu due à la localisation des environnements virtuels et des chemins python associés - pour autant que je sache, c'était une cause importante de bogues et de ruptures et ne fonctionnait fondamentalement pas. Le fait qu'il brise les flux de travail est la première fois que j'en entends parler .

Ceci n'est pas destiné à être un changement de rupture, il vise à empêcher une interaction précédemment interrompue - pour toute personne pour qui cela fonctionnait, veuillez inclure l'ensemble complet des arguments de ligne de commande que vous passiez à pipenv (par exemple pipenv install --<whatever> et des informations sur votre flux de travail:

• utilisiez-vous docker? une autre infrastructure de conteneurs?
• quel utilisateur invoquait la commande? quel UID (en gros, était-ce un compte root)
• étiez-vous en train --system passer
• sous quel système d'exploitation pipenv fonctionnait-il?
• Quelle version de python?

C'est probablement assez pour le moment

@techalchemy Ce sont les parties pertinentes de notre Dockerfile qui ne fonctionnent plus.

FROM python:3.8

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

@techalchemy Merci d'avoir sollicité des cas d'utilisation. Voici un autre exemple:

• Scénario de conteneurisation: oui, mais pas strictement Docker (images OCI)
• Pipenv s'exécute dans l'environnement de construction du conteneur avec uid = 0
• L'indicateur --system n'est pas passé
• Linux
• Python 3.8

Au cas où cela serait utile pour enquêter ou reproduire le problème, les étapes de génération sont visibles dans cette cible Make .

Pour tous ceux qui souhaitent utiliser le dernier pipenv avec --system , adapter votre Dockerfile en définissant un WORKDIR et en y copiant votre Pipfile / lockfile comme suit peut être utile:

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

• bâtiment dockerfile
• racine
• voir le code ci-dessous
• python:3-slim image docker, livré avec 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

Pour tous ceux qui souhaitent utiliser le dernier pipenv avec --system , adapter votre Dockerfile en définissant un WORKDIR et en y copiant votre Pipfile / lockfile comme suit peut être utile:

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

Cela a fonctionné pour moi. N'oubliez pas de créer le répertoire /code avant.

Cela a fonctionné pour moi. N'oubliez pas de créer le répertoire /code avant.

la commande WORKDIR crée déjà le répertoire s'il n'existe pas

Utiliser WORKDIR n'a pas fonctionné pour moi. Je reçois une erreur

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

lors de l'utilisation de dockerfile ci-dessous

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

cela ne semble pas être une erreur de construction, voir # 4220

En passant, $PIP_USER n'est pas défini par pipenv et je suis relativement incertain sur la façon dont $PYTHONUSERBASE interagit avec lui

De plus, le drapeau --deploy serait quelque peu inutile avec le drapeau --ignore-pipfile - --deploy est utilisé pour garantir que votre Pipfile et votre Pipfile.lock sont alignés, c'est à dire que votre Pipfile.lock été généré à partir du Pipfile . Si vous indiquez que vous souhaitez ignorer votre fichier pip, cette vérification ne se produit jamais.

Dans tous les cas @killuazhu, l'erreur dans les journaux que vous avez inclus est peut-être liée aux manipulations de votre chemin python, mais nécessitera une enquête plus approfondie si vous pouvez déposer un problème séparé

Pour référence, le problème original de # 3434 se produit lorsque l'on essaie de pipenv install sous / sans Pipfile. Et la configuration dans ce ticket est de pipenv install sous / avec un Pipfile, qui fonctionnait auparavant sur 2018.11.26. Cependant, # 3386 a choisi une approche de résolution incorrecte, qui empêche complètement l'utilisation à partir du répertoire racine.

Merci pour la correction, avez-vous un ETA sur le moment où le correctif sera inclus dans une nouvelle version du paquet pypi?

nous devons nous assurer que tous les problèmes de régression sont résolus et que la nouvelle version sortira la semaine prochaine

Super merci, appréciez-le!

Je peux confirmer que ce comportement ne se produit pas sur la version 2018.11.26 .

@mohamedMok Vous pouvez utiliser pip install 'pipenv==2018.11.26' qui est la dernière version qui n'a pas ce changement de rupture.

J'obtenais une erreur légèrement différente lors de l'exécution de python3 -m pipenv install --three --system

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

L'épinglage à l'ancienne version a également fonctionné pour moi. Merci!

Je peux confirmer que ce comportement ne se produit pas sur la version 2018.11.26 .
@mohamedMok Vous pouvez utiliser pip install 'pipenv==2018.11.26' qui est la dernière version qui n'a pas ce changement de rupture.

J'obtenais une erreur légèrement différente lors de l'exécution de python3 -m pipenv install --three --system

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

L'épinglage à l'ancienne version a également fonctionné pour moi. Merci!

J'ai le même problème. Épingler maintenant à l'ancienne version comme solution de contournement

nous devons nous assurer que tous les problèmes de régression sont résolus et que la nouvelle version sortira la semaine prochaine

Ce problème est toujours présent dans la version 2020.6.2:

Production:
Échec du chargement des chemins: / bin / sh: 1: /root/.local/share/virtualenvs/app-lp47FrbD/bin/python: introuvable

Pourriez-vous confirmer si ce problème devait être résolu dans la version 2020.6.2?

Je peux confirmer que je rencontre ce problème avec les 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 Pouvez-vous rouvrir le numéro?

Je peux également confirmer que je rencontre ce problème avec le Dockerfile suivant:

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"]

Voici l'erreur:

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

Pour les personnes ayant encore ce problème, la solution la plus simple consiste à configurer votre Dockerfile comme:

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
...