Pipenv: Pipenv, das nicht mehr im Stammverzeichnis arbeitet, wird nicht als wichtige Änderung aufgeführt

hi @ gps035 ,

Ich habe das gleiche Problem mit pipenv.
Könnten Sie bitte zeigen, wie Sie die Version pipenv gepinnt haben?

Vielen Dank

Ich kann bestätigen, dass dieses Verhalten bei Version 2018.11.26 nicht auftritt.

@mohamedMok Sie können pip install 'pipenv==2018.11.26' Dies ist die letzte Version, die diese grundlegende Änderung nicht aufweist.

@ gps035 Gibt es eine Chance, eine PR zu senden, um sie im CHANGELOG zu erwähnen?

Ich habe eine PR eingereicht, um dieses Problem zu beheben. Vielen Dank für alle.

Keine lustigen Änderungen, alle unsere Docker verwenden während des Builds die Installation von pipenv: /

Stoßen Sie auf dasselbe Problem, indem Sie das Update in https://github.com/pypa/pipenv/issues/4273#issuecomment -635303079 verwenden, das für mich funktioniert hat.

Unsere Docker-Builds sind heute Morgen aufgrund einer Verhaltensänderung beim Ausführen von pipenv install im Stammverzeichnis fehlgeschlagen.

Können Sie den Workflow hier erklären - verwenden Sie --system ?

Wie ich gerade in # 4275 erwähnt habe:

Der Hauptgrund für die Änderung liegt in erster Linie in der Suche nach virtuellen Umgebungen und verwandten Python-Pfaden. Soweit mir bekannt war, war dies eine wesentliche Ursache für Fehler und Brüche und funktionierte im Grunde nicht. Die Tatsache, dass es Workflows unterbricht, ist das erste Mal, dass ich davon höre, dass es überhaupt funktioniert .

Dies ist keine brechende Änderung, sondern soll eine zuvor unterbrochene Interaktion verhindern. Geben Sie für alle Personen, für die dies funktioniert hat, den vollständigen Satz von Befehlszeilenargumenten an, die Sie an pipenv übergeben haben (z. B. pipenv install --<whatever> und Informationen zu Ihrem Workflow:

• Hast du Docker benutzt? eine andere Containerinfrastruktur?
• Welcher Benutzer hat den Befehl aufgerufen? welche UID (im Grunde war es ein Root-Account)
• Haben Sie --system an pipenv übergeben, Ihre eigene virtuelle Umgebung erstellt oder pipenv erlaubt, eine für Sie zu erstellen?
• Unter welchem ​​Betriebssystem lief pipenv?
• Welche Python-Version?

Das ist wahrscheinlich genug für jetzt

@techalchemy Dies sind die relevanten Teile unserer Docker-Datei, die nicht mehr funktionieren.

FROM python:3.8

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

@techalchemy Vielen Dank, dass Sie Anwendungsfälle ausgewählt haben. Hier ist ein weiteres Beispiel:

• Containerisierungsszenario: Ja, obwohl nicht ausschließlich Docker (OCI-Images)
• Pipenv wird in der Container-Build-Umgebung als uid = 0 ausgeführt
• Das Flag --system wird nicht übergeben
• Linux
• Python 3.8

Falls es für die Untersuchung oder Reproduktion des Problems nützlich ist, werden die Erstellungsschritte in diesem Make-Ziel angezeigt .

Für alle, die das neueste Pipenv mit --system möchten, kann es hilfreich sein, Ihr Dockerfile anzupassen, indem Sie ein WORKDIR festlegen und Ihr Pipfile / Lockfile wie folgt kopieren:

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

• Docker-Datei erstellen
• Wurzel
• siehe Code unten
• python:3-slim Docker-Bild, kommt mit 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

Für alle, die das neueste Pipenv mit --system möchten, kann es hilfreich sein, Ihr Dockerfile anzupassen, indem Sie ein WORKDIR festlegen und Ihr Pipfile / Lockfile wie folgt kopieren:

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

Das hat bei mir funktioniert. Denken Sie daran, vorher das Verzeichnis /code zu erstellen.

Das hat bei mir funktioniert. Denken Sie daran, vorher das Verzeichnis /code zu erstellen.

Der Befehl WORKDIR erstellt das Verzeichnis bereits, wenn es nicht vorhanden ist

Die Verwendung von WORKDIR hat bei mir nicht funktioniert. Ich bekomme einen Fehler

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

bei Verwendung der Docker-Datei unten

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

Dies scheint kein Build-Fehler zu sein, siehe # 4220

Als Nebenbemerkung wird $PIP_USER von pipenv nicht gesetzt und ich bin relativ unsicher, wie $PYTHONUSERBASE interagiert

Außerdem wäre die Flagge --deploy Flagge --ignore-pipfile etwas sinnlos - --deploy wird verwendet, um sicherzustellen, dass Ihre Pipfile und Ihre Pipfile.lock sind ausgerichtet, dh dass Ihr Pipfile.lock aus dem entsprechenden Pipfile generiert wurde. Wenn Sie angeben, dass Sie Ihre Pip-Datei ignorieren möchten, wird diese Überprüfung nie durchgeführt.

In jedem Fall @killuazhu hängt der Fehler in den von Ihnen enthaltenen Protokollen möglicherweise mit den Manipulationen Ihres Python-Pfads zusammen, erfordert jedoch weitere Untersuchungen, wenn Sie ein separates Problem einreichen können

Als Referenz tritt die ursprüngliche Ausgabe von # 3434 auf, wenn man versucht, pipenv install unter / ohne Pipfile zu machen. Und das Setup in diesem Ticket ist auf pipenv install unter / mit einem Pipfile, das am 26.11.2018 funktioniert hat. # 3386 hat jedoch einen falschen Auflösungsansatz gewählt, der die Verwendung aus dem Stammverzeichnis vollständig verhindert.

Vielen Dank für die Korrektur. Haben Sie eine ETA, wann die Korrektur in einer neuen Version des Pypi-Pakets enthalten sein wird?

Wir müssen sicherstellen, dass alle Regressionsprobleme behoben sind und die neue Version in der nächsten Woche veröffentlicht wird

Super danke, danke!

Ich kann bestätigen, dass dieses Verhalten bei Version 2018.11.26 nicht auftritt.

@mohamedMok Sie können pip install 'pipenv==2018.11.26' Dies ist die letzte Version, die diese grundlegende Änderung nicht aufweist.

Beim Ausführen von python3 -m pipenv install --three --system wurde ein etwas anderer Fehler

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

Das Anheften an die alte Version hat auch bei mir funktioniert. Vielen Dank!

Ich kann bestätigen, dass dieses Verhalten bei Version 2018.11.26 nicht auftritt.
@mohamedMok Sie können pip install 'pipenv==2018.11.26' Dies ist die letzte Version, die diese grundlegende Änderung nicht aufweist.

Beim Ausführen von python3 -m pipenv install --three --system wurde ein etwas anderer Fehler

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

Das Anheften an die alte Version hat auch bei mir funktioniert. Vielen Dank!

Ich habe das gleiche Problem. Fixieren Sie jetzt die alte Version als Problemumgehung

Wir müssen sicherstellen, dass alle Regressionsprobleme behoben sind und die neue Version in der nächsten Woche veröffentlicht wird

Dieses Problem ist in der Version 2020.6.2 noch vorhanden:

Ausgabe:
Fehler beim Laden der Pfade: / bin / sh: 1: /root/.local/share/virtualenvs/app-lp47FrbD/bin/python: nicht gefunden

Könnten Sie bitte bestätigen, ob dieses Problem voraussichtlich in der Version 2020.6.2 behoben wird?

Ich kann bestätigen, dass ich dieses Problem mit den folgenden 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 Können Sie das Problem bitte erneut öffnen?

Ich kann auch bestätigen, dass ich dieses Problem mit der folgenden Docker-Datei habe:

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

Hier ist der Fehler:

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

Für Leute, die immer noch dieses Problem haben, ist es am einfachsten, Ihre Docker-Datei wie folgt zu konfigurieren:

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