Pip: Assertion bei Verwendung von --no-cache-dir in 19.0

Das Gleiche passiert mit:
Python v3.6.8
pip version 18.1
auf
Ubuntu:latest Bild.

@snstanton Welches Basis-Image verwenden Sie? Ich sehe ein ähnliches Problem auch in Pip v18.1

Ich habe genau das gleiche Problem.
Auf meiner Seite scheint es egal zu sein, welches Paket / welche Distribution ich zu installieren versuche

Ich sehe das auch ohne --no-cache-dir gesetzt. Dies passiert für alle Pakete, die ich zu installieren versuche, auch wenn sie bereits installiert sind.

• Pip-Version: 19.0
• Python-Version: 3.6.0
• Betriebssystem: Ubuntu 14.04.4 LTS (GNU / Linux 3.13.0-91-generic x86_64)

Ich sollte beachten, dass ich es in meinem Fall sehe, wenn ich pip mit einer Kombination aus sudo -H und bash -l -c .

$ sudo -H bash -l -c  "/data/virtualenvs/events_beta/bin/pip install hypothesis"
Looking in indexes: https://pypi.org/simple, http://pypi.lan.cogtree.com/cogtree/simple/
Collecting hypothesis
  Downloading http://pypi.lan.cogtree.com/cogtree/simple/hypothesis/hypothesis-4.1.0-py3-none-any.whl (238kB)
    100% |████████████████████████████████| 245kB 120.5MB/s
Requirement already satisfied: attrs>=16.0.0 in /data/virtualenvs/events_beta/lib/python3.6/site-packages (from hypothesis) (18.2.0)
Exception:
Traceback (most recent call last):
  File "/data/virtualenvs/events_beta/lib/python3.6/site-packages/pip/_internal/cli/base_command.py", line 176, in main
    status = self.run(options, args)
  File "/data/virtualenvs/events_beta/lib/python3.6/site-packages/pip/_internal/commands/install.py", line 346, in run
    session=session, autobuilding=True
  File "/data/virtualenvs/events_beta/lib/python3.6/site-packages/pip/_internal/wheel.py", line 848, in build
    assert building_is_possible
AssertionError

Wenn Sie dieselben Befehle ausführen, ohne -l auf meinem bash -c oder ohne bash -l -c , funktioniert alles einwandfrei.

$ sudo -H bash -c  "/data/virtualenvs/events_beta/bin/pip install hypothesis"
Collecting hypothesis
  Downloading https://files.pythonhosted.org/packages/89/7b/d6206dcde963139daa03a1d85b0c3428cb3ebf2ae8de3244b14a63e22680/hypothesis-4.1.0.tar.gz (180kB)
    100% |████████████████████████████████| 184kB 33.7MB/s
Requirement already satisfied: attrs>=16.0.0 in /data/virtualenvs/events_beta/lib/python3.6/site-packages (from hypothesis) (18.2.0)
Building wheels for collected packages: hypothesis
  Building wheel for hypothesis (setup.py) ... done
  Stored in directory: /root/.cache/pip/wheels/10/12/eb/4ab734432e8466d545c8501f531458845b45e8c4427d5367f9
Successfully built hypothesis
Installing collected packages: hypothesis
Successfully installed hypothesis-4.1.0

Es ist faszinierend, wenn ich denselben Befehl ohne sudo oder bash ausführe, schlägt er immer noch mit demselben Fehler fehl, sodass es sich anscheinend um ein seltsames Berechtigungsproblem handelt.

Eine weitere Problemumgehung für einige Situationen

Für Leute, die diesen Fehler haben, weil virtualenv automatisch die neueste Version von pip installiert, können Sie dies umgehen, indem Sie virtualenv die Option --no-download oder VIRTUALENV_NO_DOWNLOAD=1 festlegen.

Beachten Sie jedoch, dass dies möglicherweise zu einer sehr alten Version von pip führt, je nachdem, wann Sie virtualenv zuletzt aktualisiert haben.

Dies funktioniert auch mit tox: VIRTUALENV_NO_DOWNLOAD=1 tox .

für das, was es wert ist: es schlägt auch mit dem gleichen Fehler fehl, wenn das Paket bereits installiert ist:

gregory.starck<strong i="6">@canon</strong>:~/tmp$ ./venv/bin/pip install --no-cache-dir six ; echo $?
Looking in indexes: http://pypi:3141/root/ax/+simple/
Requirement already satisfied: six in ./venv/lib/python3.6/site-packages (1.12.0)
Exception:
Traceback (most recent call last):
  File "/home/gregory.starck/tmp/venv/lib/python3.6/site-packages/pip/_internal/cli/base_command.py", line 176, in main
    status = self.run(options, args)
  File "/home/gregory.starck/tmp/venv/lib/python3.6/site-packages/pip/_internal/commands/install.py", line 346, in run
    session=session, autobuilding=True
  File "/home/gregory.starck/tmp/venv/lib/python3.6/site-packages/pip/_internal/wheel.py", line 848, in build
    assert building_is_possible
AssertionError
2
gregory.starck<strong i="7">@canon</strong>:~/tmp$

Bin auf das gleiche Problem gestoßen. Ich habe die Pip-Version vorerst als Fix fixiert.

pip install --upgrade pip==18.1

Das Problem besteht darin, dass die Bestätigung fehlschlägt. Wenn Sie also env PYTHONOPTIMIZE = 1 (oder den Parameter -O) festlegen, wird dieser Fehler behoben.
Habe es gerade getestet.
Diese Problemumgehung funktioniert, da Python den Code optimiert, indem alle Asserts als eines der Dinge entfernt werden.
Wählen Sie nicht = 2 (oder -OO), da dadurch Dokumentzeichenfolgen entfernt werden und andere Tracebacks angezeigt werden. Einige Codes möchten diese bearbeiten.

Es sieht so aus, als hätte jemand gewusst, dass dies ein Problem sein könnte ( Quelle ):

        # TODO: This check fails if --no-cache-dir is set. And yet we
        #       might be able to build into the ephemeral cache, surely?
        building_is_possible = self._wheel_dir or (
            autobuilding and self.wheel_cache.cache_dir
        )
        assert building_is_possible

https://github.com/pypa/pip/pull/5884 sieht so aus, als wäre dies eine verwandte Änderung, die dies verursacht haben könnte?

Scheint, als sollten die Pip-Betreuer die jüngste Version 19 zurücksetzen, um diese bahnbrechende Änderung zu beheben?
Versionshinweise zu 19.0: https://github.com/pypa/pip/blob/master/NEWS.rst#190 -2019-01-22

UPDATE: Ich habe nicht versucht, hier Aspersionen zu machen, sondern nur einen Weg vorgeschlagen, um die von dieser Betroffenheit betroffenen Personen schnell freizugeben, da die Veröffentlichung gerade stattgefunden hatte. Das Vorwärtsrollen mit einem Hotfix funktioniert auch. Ich schätze die harte Arbeit der Community, die dieses unternehmenskritische Tool unterstützt, und stimme den folgenden Ansichten zu Postmortems zu, um aus Fehlern zu lernen und zukünftige Probleme zu vermeiden. In der Zwischenzeit machen wir intern dasselbe, was bedeutet, dass an allen Orten eine liberale Menge an feststeckenden pip -Versionen vorhanden ist :)

Der PR, der den TODO-Kommentar hinzufügt, hat auch diesen Kommentar als Antwort: https://github.com/pypa/pip/pull/5743/files#r215832743

Basierend auf diesem Kommentar und dem obigen Kommentator, der sagt, dass das Übergeben von PYTHONOPTIMIZE=1 den Fehler verschwinden lässt, scheint es einfach die richtige Lösung zu sein, die Behauptung zu entfernen (unabhängig von der Frage des Rollbacks).

Ja, wenn ich diese Behauptung lösche, werden Pakete mit --no-cache-dir einwandfrei installiert. In diesem Fall heißt es, es sei Running setup.py install anstelle von Building wheel für SDIST-Pakete.

Dies passiert auch bei meinen Projekten. Ich kann dies in Docker-Images reproduzieren, die FROM ubuntu:bionic und FROM centos:centos7 denen ich Python 3 von der Quelle aus installiere (hier ist eine Übersicht, die ein fehlerhaftes Beispiel für beide Docker-Images für den Fall zeigt, dass dies der Fall ist könnte hilfreich sein). Für die requirements.txt im Beispiel im Gist und

$ pip3 install --upgrade pip setuptools wheel
Requirement already up-to-date: pip in /usr/lib/python3.6/site-packages (19.0)
Requirement already up-to-date: setuptools in /usr/lib/python3.6/site-packages (40.6.3)
Requirement already up-to-date: wheel in /usr/lib/python3.6/site-packages (0.32.3)

dann

$ pip3 install --upgrade --no-cache-dir -r requirements.txt

scheitert mit

Exception:
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/pip/_internal/cli/base_command.py", line 176, in main
    status = self.run(options, args)
  File "/usr/lib/python3.6/site-packages/pip/_internal/commands/install.py", line 346, in run
    session=session, autobuilding=True
  File "/usr/lib/python3.6/site-packages/pip/_internal/wheel.py", line 848, in build
    assert building_is_possible
AssertionError

aber

$ pip3 install --upgrade -r requirements.txt

funktioniert wie erwartet.

Ich treffe dies besonders mit tox + docker + ENV PIP_NO_CACHE_DIR=off

Meine Problemumgehung besteht darin, das Plugin tox-virtualenv-no-download zu verwenden, um zu verhindern, dass pip automatisch aktualisiert wird

Wir haben auch --no-cache-dir in unseren Installationen in Docker, um die Bilder klein zu halten. Unsere Problemumgehung war --cache-dir=/pipcache und dann rm -rf /pipcache im selben Schritt RUN , sodass es nie im Bild landet.

Die Softwareentwicklung ist schwierig und solche Fehler werden immer auftreten. Sicherlich sollte niemand die pip Betreuer oder Mitwirkenden für diesen Vorfall verantwortlich machen.

Ich würde jedoch vorschlagen, dass dieser Fehler eine Art Post-Mortem-Analyse seitens des Pip-Teams verdient, da es viele (verpasste) Möglichkeiten gibt, diesen Fehler zu erkennen, bevor er in eine allgemeine Version aufgenommen wird. Zum Beispiel:

• automatisiertes Testen von Kernfunktionen wie --no-cache-dir
• Pre-Commit-, Pre-Merge- oder Pre-Release-Überprüfungen, die TODO s kennzeichnen (oder verbieten)
• eine (menschliche) Überprüfung aller ungelösten Überprüfungskommentare in der PR vor dem Zusammenführen (Github automatisiert die meisten Überprüfungskommentarthreads automatisch, wenn der zugehörige Code geändert wurde, und seit kurzem können Sie Überprüfungskommentarthreads manuell als gelöst markieren).
• Änderungen im Release-Prozess - warum nicht zuerst eine Beta veröffentlichen und dann einige Wochen vor einer allgemeinen Veröffentlichung warten?
• usw

Ein Postmortem könnte zu einer Reihe hilfreicher Verbesserungen führen, um sicherzustellen, dass Software, die für das Python-Projekt genauso wichtig ist wie pip in Zukunft nicht mehr mit Fehlern dieser Größenordnung ausgeliefert wird.

Ich kann diesen Fehler replizieren. Durch Entfernen von --no-cache-dir wird das Problem behoben. Da ich es nicht in meinem Docker-Image haben möchte, verwende ich die vorgeschlagene Lösung @coderanger . Prost 🌈🍰🌈

Dies sieht aus wie ein Duplikat von Ausgabe 6166

Schnelle und einfache Reproduktion Dockerfile:

FROM buildpack-deps:buster
ENV LANG C.UTF-8
ENV LC_ALL C.UTF-8
RUN apt-get update && apt-get install -y --no-install-recommends python3-dev && rm -rf /var/lib/apt/lists/*
RUN curl https://bootstrap.pypa.io/get-pip.py | python3 - --no-cache-dir

Das einfache Entfernen der Behauptung könnte die richtige Lösung sein

Nicht genau - ich denke, wir sollten dies für die nicht kurzlebigen Builds beibehalten. Ich werde eine Bugfix-PR einreichen, sobald ich mit dem Frühstück fertig bin. :) :)

@ Pradyunsg Überprüfen Sie meine PR auf einen fehlgeschlagenen Test

Für mich kann pip v19.0 nichts installieren, wenn die Option --no-cache (oder --no-cache-dir ) verwendet wird.

Ich habe # 6171 als Bugfix für dieses Problem eingereicht. Könnten Leute aus diesem Thread diese PR ausprobieren und überprüfen, ob sie dieses Problem tatsächlich behebt?

PS: Vielen Dank an @tgs für die Einreichung einer PR, um dieses Problem schnell zu beheben! :) :)

wfm, danke für das Update!

$ pip install pip --upgrade
Requirement already up-to-date: pip in ./venv/lib/python3.6/site-packages (19.0)
$ pip install --no-cache-dir pip
Requirement already satisfied: pip in ./venv/lib/python3.6/site-packages (19.0)
Exception:
Traceback (most recent call last):
  File "/tmp/venv/lib/python3.6/site-packages/pip/_internal/cli/base_command.py", line 176, in main
    status = self.run(options, args)
  File "/tmp/venv/lib/python3.6/site-packages/pip/_internal/commands/install.py", line 346, in run
    session=session, autobuilding=True
  File "/tmp/venv/lib/python3.6/site-packages/pip/_internal/wheel.py", line 848, in build
    assert building_is_possible
AssertionError
$ pip install git+https://github.com/pradyunsg/pip@fix/pep-517-building-assertion
Collecting git+https://github.com/pradyunsg/pip@fix/pep-517-building-assertion
  Cloning https://github.com/pradyunsg/pip (to revision fix/pep-517-building-assertion) to ./pip-req-build-g_3qep31
Branch 'fix/pep-517-building-assertion' set up to track remote branch 'fix/pep-517-building-assertion' from 'origin'.
Switched to a new branch 'fix/pep-517-building-assertion'
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
    Preparing wheel metadata ... done
Building wheels for collected packages: pip
  Building wheel for pip (PEP 517) ... done
  Stored in directory: /tmp/pip-ephem-wheel-cache-sb1_muik/wheels/bd/86/cd/7688dba746eabc598fb37d4a93e2ff9bd05a6d9f907ee7b6cd
Successfully built pip
Installing collected packages: pip
  Found existing installation: pip 19.0
    Uninstalling pip-19.0:
      Successfully uninstalled pip-19.0
Successfully installed pip-19.1.dev0
$ pip install --no-cache-dir astpretty  # downloads a wheel
Collecting astpretty
  Downloading https://files.pythonhosted.org/packages/9d/10/cb0c3a3edb16f45be05bdba7f37798fcddb8cf085def8cb6e62b2ad7c711/astpretty-1.4.1-py2.py3-none-any.whl
Installing collected packages: astpretty
Successfully installed astpretty-1.4.1
$ pip install --no-cache-dir simplejson  # requires building
Collecting simplejson
  Downloading https://files.pythonhosted.org/packages/e3/24/c35fb1c1c315fc0fffe61ea00d3f88e85469004713dab488dee4f35b0aff/simplejson-3.16.0.tar.gz (81kB)
    100% |████████████████████████████████| 81kB 1.0MB/s 
Installing collected packages: simplejson
  Running setup.py install for simplejson ... done
Successfully installed simplejson-3.16.0

Ich hoffe, PR6171 bald zusammenzuführen und Version 19.0.1 zu veröffentlichen

Die Leute sollten Pip in CI wirklich pinnen, wie Sie es für jedes andere Paket oder jede andere Abhängigkeit tun würden, IMO. Andernfalls haben Sie keine Reproduzierbarkeit und riskieren plötzliche Brüche. Durch Fixieren können Sie die Dinge im Voraus überprüfen und in Ihrem eigenen Tempo aktualisieren.

Die Leute sollten Pip in CI wirklich pinnen, wie Sie es für jedes andere Paket oder jede andere Abhängigkeit tun würden, IMO. Andernfalls haben Sie keine Reproduzierbarkeit und riskieren plötzliche Brüche. Durch Fixieren können Sie die Dinge im Voraus überprüfen und in Ihrem eigenen Tempo aktualisieren.

@cjerdonek : Ich stimme Ihnen zu, dass es aus Sicht der pip Benutzer eine gute Idee ist, pip in vielen (vielleicht den meisten) Kontexten zu pinnen. Zumindest sollten Sie wissen, dass Sie genau so etwas riskieren, wenn Sie nicht pinnen, und Sie können sich nicht bei den pip Betreuern beschweren, wenn es passiert!

Allerdings ... aus Sicht von pip Betreuern (und allgemeiner aus Sicht von PyPA- oder Python-Kernteams) halte ich es für ratsam, die Tatsache zu betrachten, dass sehr viele Leute nicht pip pinnen nicht intuitiv. Oft sind die wichtigsten Tools

Vorfälle wie diese untergraben dieses Vertrauen. Die fehlerhaften CI-Builds sind nicht das eigentliche Problem (wie Sie sagen, Sie sollten entweder pip in CI-Builds anheften oder sich dessen bewusst sein, was Sie riskieren), sondern sind ein Symptom - oder vielmehr eine korrelierte Warnung - das erodierte Vertrauen.

Aus diesem Grund habe ich vorgeschlagen, dass dieser Vorfall einen (tadellosen) Postmortem-Prozess verdient. Kein pip Betreuer sollte sich im Moment schlecht fühlen, aber dies ist ein ernstes Problem und sollte auf Verbesserungen untersucht werden.

Ja, solche Vorfälle helfen nicht, Vertrauen aufzubauen. Wir werden eine Obduktion haben, um herauszufinden, wie diese vermieden werden können (wir tun dies nach jeder Veröffentlichung, da es immer Verbesserungsmöglichkeiten gibt).

Vielen Dank für die (größtenteils) Aufrechterhaltung des richtigen Diskurses und für die konstruktiven Kommentare! Normalerweise sind die Dinge für uns viel ätzender, wenn es ein solches Problem gibt. :) :)

Trotzdem gibt es noch ein paar andere Fehlerberichte, die wir uns ansehen müssen, und wir werden bald genug eine 19.0.1 haben.

Ich denke, der Schlüssel hier ist, dass dies gezeigt hat, dass wir nicht genügend Tests haben, um unter --no-cache-dir . Zusätzliche Tests in diesem Bereich wären eine große Hilfe, um solche Regressionen zu vermeiden, und allgemeiner wäre eine Überprüfung der unterbewerteten "Schlüsselfunktionen" hilfreich.

Als Pip-Betreuer würde ich sagen, dass ein Problem darin besteht, zu wissen, was die Leute als "Schlüsselfunktionalität" betrachten. Persönlich hätte ich angenommen, dass --no-cache-dir eine ziemlich Nische ist, daher ist meine Intuition in diesem Fall offensichtlich nicht zuverlässig :-) Daher ist ein solches Feedback besonders wertvoll.

Ich denke, es kann bald 19.0.1 nur für diesen Fehler veröffentlicht werden, schließlich ist es bedeutend und dringend. Ein weiterer Fehlerbericht kann in 19.0.2 nach Tag behoben werden.

Als Pip-Betreuer würde ich sagen, dass ein Problem darin besteht, zu wissen, was die Leute als "Schlüsselfunktionalität" betrachten. Persönlich hätte ich angenommen, dass --no-cache-dir eine ziemlich Nische ist, daher ist meine Intuition in diesem Fall offensichtlich nicht zuverlässig :-) Daher ist ein solches Feedback besonders wertvoll.

Der einzige Grund, warum ich --no-cache-dir , ist die Installation von mpi4py .
Auf diese Weise kann ich erzwingen, dass es vor der Installation erneut heruntergeladen und neu erstellt wird, und sicherstellen, dass alle an meiner MPI-Distribution vorgenommenen Änderungen berücksichtigt werden.

Das gleiche Problem hier, das außerhalb unseres CI-Systems reproduziert werden kann. Um dieses Problem zu umgehen, haben wir ein Downgrade auf Pip 18.1.0 durchgeführt und alles funktioniert:

pip install pip==18.1.0

Hoffe und aktualisiere bald.

Ich werde benützen:

pip install "pip!=19.0"

Hoffe 19.1 ist behoben :)

Ich vermute, wir werden relativ bald eine 19.0.1 mit Korrekturen für die aufkommenden Probleme haben.

Ich bin gespannt, ob das Einschließen von --no-use-pep517 zusammen mit --no-cache-dir eine weitere Problemumgehung für dieses Problem darstellt, ebenso wie für ein anderes Problem im Zusammenhang mit PEP 517: https://github.com/pypa/pip / Issues / 6163 # issuecomment -456772043

Als Pip-Betreuer würde ich sagen, dass ein Problem darin besteht, zu wissen, was die Leute als "Schlüsselfunktionalität" betrachten. Persönlich hätte ich angenommen, dass --no-cache-dir eine ziemlich Nische ist, daher ist meine Intuition in diesem Fall offensichtlich nicht zuverlässig :-) Daher ist ein solches Feedback besonders wertvoll.

FWIW: Ich verwende --no-cache-dir ziemlich oft beim Erstellen von Docker-Images, um zu verhindern, dass Cache-Cruft in einer Umgebung zurückbleibt, in der dies nicht sinnvoll ist.

Die Leute sollten Pip in CI wirklich pinnen, wie Sie es für jedes andere Paket oder jede andere Abhängigkeit tun würden, IMO. Andernfalls haben Sie keine Reproduzierbarkeit und riskieren plötzliche Brüche. Durch Fixieren können Sie die Dinge im Voraus überprüfen und in Ihrem eigenen Tempo aktualisieren.

In vielen Umgebungen ist pip keine Abhängigkeit. Es wird beim Erstellen der virtuellen Umgebung installiert.

Übrigens wird dort nicht getestet, ob Ihr Produkt mit den neuesten Versionen funktioniert. Das Anheften von allem führt nur zu alten Versionen. Und das Aktualisieren wird bald eine Aufgabe sein, die niemand zu beginnen wagt. Kenne ich schon. Meine Meinung ist also nur zu pinnen, wenn es wirklich nötig ist. Und versuchen Sie, das Problem zu beheben, sobald es auftritt.

pip 19.0.1 hat das Update für dieses Problem nicht mehr verfügbar.

Ich war gespannt auf die neue Version 19.0.1, hatte aber immer noch ein Problem. Ich erstelle auch ein Docker-Image mit --no-cache-dir , das mit pip <19.0 gut funktioniert. Bekommt sonst noch jemand das?

Exception:
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/pip/_internal/cli/base_command.py", line 176, in main
    status = self.run(options, args)
  File "/usr/lib/python3.6/site-packages/pip/_internal/commands/install.py", line 346, in run
    session=session, autobuilding=True
  File "/usr/lib/python3.6/site-packages/pip/_internal/wheel.py", line 886, in build
    assert have_directory_for_build
AssertionError

Ich war gespannt auf die neue Version 19.0.1, hatte aber immer noch ein Problem. Ich erstelle auch ein Docker-Image mit --no-cache-dir , das mit pip <19.0 gut funktioniert. Bekommt sonst noch jemand das?

Fix funktioniert bei mir mit 19.0.1 - Ich vermute, Sie haben einen Docker-Layer-Cache, der Sie verwirrt? - Versuchen Sie pip --version , um zu überprüfen, auf welcher Version Sie sich befinden

Ich habe eine Python- und Pip-Versionsprüfung in allen meinen Docker-Dateien und sie meldet 19.0.1 korrekt.

@dmulter Ich habe heute Morgen meine Docker-Bilder in meinem Gist von Grund auf neu erstellt und dort funktioniert es mit v19.0.1 einwandfrei . Können Sie Ihre Docker-Datei auch in einem Gist freigeben, damit wir sie uns alle ansehen können?

Ich habe einfach alles wieder gereinigt, nur um sicherzugehen. Hier ist die Docker-Datei und meine Build-Ausgabe .

Siehe meinen Hinweis zur Build-Ausgabe für die verwendeten Docker-Befehle.

Gibt es ein Update für pip3? Hier ist der Fehler, den ich bekommen habe ...

> pip3 install --upgrade 'pip>=19.01' setuptools

  Could not find a version that satisfies the requirement pip>=19.01 (from versions: 0.2, 0.2.1, 0.3, 0.3.1, 0.4, 0.5, 0.5.1, 0.6, 0.6.1, 0.6.2, 0.6.3, 0.7, 0.7.1, 0.7.2, 0.8, 0.8.1, 0.8.2, 0.8.3, 1.0, 1.0.1, 1.0.2, 1.1, 1.2, 1.2.1, 1.3, 1.3.1, 1.4, 1.4.1, 1.5, 1.5.1, 1.5.2, 1.5.3, 1.5.4, 1.5.5, 1.5.6, 6.0, 6.0.1, 6.0.2, 6.0.3, 6.0.4, 6.0.5, 6.0.6, 6.0.7, 6.0.8, 6.1.0, 6.1.1, 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.1.0, 7.1.1, 7.1.2, 8.0.0, 8.0.1, 8.0.2, 8.0.3, 8.1.0, 8.1.1, 8.1.2, 9.0.0, 9.0.1, 9.0.2, 9.0.3, 10.0.0b1, 10.0.0b2, 10.0.0, 10.0.1, 18.0, 18.1, 19.0)
No matching distribution found for pip>=19.01
You are using pip version 10.0.1, however version 19.0 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.

@ MrAtheist Sie haben einen kleinen Tippfehler / es fehlt eine Dezimalstelle. Die Patch-Version ist 19.0.1 aber Sie haben 19.01 geschrieben.

Hoppla, mein Fehler, aber so oder so, die möglichen Versionen haben nicht 19.0.1 aufgelistet ... ¯_ (ツ) _ / ¯

Wie bei @dmulter finde ich das Problem immer noch ungelöst. Auszug aus der Build-Ausgabe:

. venv/bin/activate;  python -m pip install --upgrade pip; python -m pip install ndg_httpsclient; python -m pip install . -i https://xxxx.yyyy.com/simple --upgrade --no-cache-dir flask
DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7.
Requirement already up-to-date: pip in ./venv/lib/python2.7/site-packages (19.0.1)
...
Requirement already satisfied, skipping upgrade: pycparser in ./venv/lib/python2.7/site-packages (from cffi>=1.1->bcrypt>=3.1.3->paramiko<3.0,>=1.10->Fabric==1.14.0->conference-gll-load-test===0.0.1-SNAPSHOT) (2.19)
Exception:
Traceback (most recent call last):
  File "/mnt/jenkins/workspace/venv/local/lib/python2.7/site-packages/pip/_internal/cli/base_command.py", line 176, in main
    status = self.run(options, args)
  File "/mnt/jenkins/workspace/venv/local/lib/python2.7/site-packages/pip/_internal/commands/install.py", line 346, in run
    session=session, autobuilding=True
  File "/mnt/jenkins/workspace/venv/local/lib/python2.7/site-packages/pip/_internal/wheel.py", line 886, in build
    assert have_directory_for_build
AssertionError
make: *** [install] Error 2

Früher im Thread hatte ich gefragt, ob das Einbeziehen von --no-use-pep517 zusammen mit --no-cache-dir die Dinge für die Leute zum

Das Hinzufügen der Option --no-use-pep517 das Problem für mich behoben. Hoffe, das hilft, die Dinge einzugrenzen.

pip 19.0.1 arbeitet für mich in einer virtuellen Umgebung. Aber in Jenkins (Shining Panda) scheitert es immer noch. Das Hinzufügen von --no-use-pep517 behebt das Problem

Ich öffne wieder, da einige Leute immer noch das gleiche Problem haben.

Ich kann auch bestätigen, dass --no-use-pep517 das Problem für mich behoben hat, nachdem ein Upgrade auf Pip 19.0.1 dies nicht getan hat.

Aber warum müssen sich all diese Projekte anpassen, wenn pip eine neue Version erhält?

Auf Anfrage von @pradyunsg habe ich eine neue Ausgabe (https://github.com/pypa/pip/issues/6197) geöffnet, die speziell für AssertionError in der Version 19.0.1 gilt, da sie enger ist im Umfang und wird neue Untersuchung benötigen. Also schließe ich dieses Problem wieder.

Bin auf das gleiche Problem gestoßen. Ich habe die Pip-Version vorerst als Fix fixiert.

pip install --upgrade pip==18.1

oder Ihr FROM python:3.6-alpine kann sich in FROM python:3.6.7-alpine ändern

Dieser Thread wurde automatisch gesperrt, da nach dem Schließen keine aktuellen Aktivitäten stattgefunden haben. Bitte öffnen Sie eine neue Ausgabe für verwandte Fehler.