Pipenv: Das Sperren ist langsam (und führt redundante Downloads durch)

@colllin Haben Sie überprüft, ob Pip-Befehle, die den Server kontaktieren - wie pip search (glaube ich) - auch langsam sind?

Ich sehe ein ähnliches Verhalten, aber es ist ein bekanntes Problem und netzwerkabhängig. Aus irgendeinem Grund ist der Zugriff auf pypi.org von meinem Arbeitsnetzwerk aus unglaublich langsam, aber normalerweise von meinem Heimnetzwerk aus schnell. Ich denke, das Sperren führt viele Pip-Transaktionen unter der Haube durch, so dass ein langsamer Zugriff auf den Server den Betrieb stark verlangsamt.

BEARBEITEN: Es kann auch sein, dass Sie nur viele Unterabhängigkeiten auflösen müssen - wie groß ist die einmal erstellte Umgebung (z. B. wie viele Pakete der obersten Ebene in Ihrer Pipdatei und wie viele Pakete von pip list sobald die Umgebung gebootstrapiert ist)?

Vielen Dank für die durchdachte Antwort.

pip search ist für mich nicht besonders schnell oder langsam... ~1 Sekunde?

Verzeihen Sie mir meine fehlenden Domänenkenntnisse: Braucht es wirklich eine Pip-Suche? Wurde nicht einfach alles installiert? Muss es nicht nur aufschreiben, was bereits installiert ist? Oder... da es die Existenz der Sperrdatei sowieso sicherstellt, könnte es dies tun, während es die Pakete

Ich vermute... pipenv verwendet Pip unter der Haube? Der Installationsprozess ist also eine Blackbox und kann das Abhängigkeitsdiagramm dessen, was installiert wurde/werden wird, nicht kennen, ohne ~eine Pip-Suche~ und seine eigenen Pip-Abfragen durchzuführen?

BEARBEITEN: Es gibt 1 Top-Level-Paket und ~65 Pakete, die von pip list in diesem speziellen Repository zurückgegeben werden.

Ich bin kein Mitwirkender an dem Projekt und kenne im Moment nicht alle Einzelheiten, aber ich verstehe, dass in der Sperrphase alle Abhängigkeiten aufgelöst und fixiert werden. Wenn Sie also ein Top-Level-Paket mit ~65 Abhängigkeiten haben, werden während der Sperrphase alle Abhängigkeiten dieses ersten Pakets (rekursiv) erkannt, und dann wird der Abhängigkeitsbaum verwendet, um aufzulösen, welche Pakete installiert werden müssen und (wahrscheinlich) in welcher groben Reihenfolge sie installiert werden sollten. Beim letzten Teil nicht so sicher.

Wenn Sie eine Pip-Installation von einer Pip-Datei aus ausführen, ohne dass eine Sperrdatei vorhanden ist, werden Sie feststellen, dass sie die Sperrphase durchführt, bevor die Pakete in das venv installiert werden. Ebenso, wenn Sie eine Sperrdatei haben, die jedoch veraltet ist. Ich vermute, eine Sperrdatei zu haben und die Installation mit der Option --deploy wäre schneller, ebenso wie die Option --no-lock ; im ersteren Fall erhalten Sie einen Fehler, wenn die Sperrdatei veraltet ist, im letzteren Fall verlieren Sie die logische Aufteilung der Pakete der obersten Ebene (deklarierte Umgebung) und der tatsächlich installierten (gesperrten) Umgebung aller Pakete. Zumindest verstehe ich das so.

Ob pipenv pip unter der Haube verwendet oder nicht - ich denke, das tut es - es muss immer noch die Informationen von den pypi-Servern über Paketabhängigkeiten und dergleichen abrufen, daher war meine Frage zur pip-Suche eher ein Proxy dafür, wie schnell oder Verlangsamen Sie Ihren Weg zum Pypi-Server als eine direkte Implikation über den Mechanismus, mit dem pipenv seine Arbeit erledigt.

Ein interessantes Experiment könnte sein, die Zeit zu vergleichen, die zum Sperren des Abhängigkeitsbaums in pipenv und zum Installieren von Anforderungen in einem neuen venv mit pip install -r requirements.txt erforderlich ist. Ich denke, sie sollten während der Phase der Abhängigkeitsauflösung ziemlich ähnliche Dinge tun.

Haben wir irgendwo festgestellt, dass es übrigens redundante Downloads gibt? Ich vermute, dass das der Fall ist, aber es zu beweisen wäre wirklich hilfreich

Zu Ihrer Information ist der Vergleich von pip install -r requirements.txt mit der Zeit, die zum Sperren eines Abhängigkeitsdiagramms benötigt wird, als Vergleichspunkt nicht aufschlussreich. Pip _hat_ eigentlich keinen Resolver, nicht im eigentlichen Sinne. Ich denke, ich kann den Unterschied beschreiben. Wenn pip Ihr requirements.txt installiert, folgt es diesem grundlegenden Prozess:

• Finden Sie die erste aufgeführte Anforderung
  
  
  
  • Finden Sie alle Abhängigkeiten
  
  
  • Installiere sie alle
  
  
• Finden Sie die zweite aufgeführte Anforderung
  
  
  
  • Finden Sie alle Abhängigkeiten
  
  
  • Installiere sie alle
  
  
• Finden Sie die dritte aufgeführte Anforderung
  
  
  
  • Finden Sie alle Abhängigkeiten
  
  
  • Installiere sie alle
  
  

Das geht ziemlich schnell, denn pip kümmert es nicht wirklich, wenn die Abhängigkeiten von _Paket 1_ mit den Abhängigkeiten von _Paket 3_ kollidieren, es hat nur die in _Paket 3_ zuletzt installiert, also bekommen Sie das.

Pipenv folgt einem anderen Prozess – wir berechnen einen Auflösungsgraphen, der versucht, _alle_ der von Ihnen angegebenen Abhängigkeiten zu erfüllen, bevor wir Ihre Umgebung erstellen. Das bedeutet, dass wir damit beginnen müssen, Pakete herunterzuladen, zu vergleichen und oft sogar zu _erstellen_, um zu bestimmen, wie Ihre Umgebung letztendlich aussehen soll, und das alles noch bevor wir mit der eigentlichen Installation begonnen haben (es gibt viele Blog-Posts darüber, warum das so ist ist in Python der Fall, daher gehe ich hier nicht weiter darauf ein).

Jeder Schritt dieses Auflösungsprozesses wird rechenintensiver, da Hashes erforderlich sind, was eine bewährte Methode ist. Wir hashen eingehende Pakete, nachdem wir sie erhalten haben, vergleichen sie dann mit den Hashes, die PyPI uns mitgeteilt hat, und speichern diese Hashes in der Lockfile, damit in Zukunft Leute, die eine identische Umgebung erstellen möchten, dies tun können die vertragliche Garantie, dass die Pakete, aus denen sie erstellt wurden, dieselben sind, die Sie ursprünglich verwendet haben.

Die Pip-Suche ist ein schlechter Maßstab für all dies, tatsächlich ist jedes der Werkzeuge von pip ein schlechter Maßstab für diese Arbeit – wir verwenden pip für jeden Teil davon, aber stellen ihn zusammen und über viele Abhängigkeiten hinweg zusammen, um ihn zu bilden und zu verwalten Umgebungen und Grafiken ist, wo der Wert von pipenv hinzugefügt wird.

Ein Punkt zur Klarstellung: Sobald Sie das vollständige Abhängigkeitsdiagramm aufgelöst haben, sollte die Installationsreihenfolge keine Rolle mehr spielen. Unter der Haube übergeben wir eigentlich sowieso --no-deps an jede Installation.

Als kleine Randnotiz ist die pip-Suche derzeit das einzige Werkzeug von pip, das auf der jetzt veralteten XMLRPC-Schnittstelle basiert, die nicht zwischenspeicherbar und sehr langsam ist. Es wird immer langsamer sein als jeder andere Vorgang.

Das Sperren von numpy (und sonst nichts) dauert 220 s auf meinem Computer (siehe unten). Die meiste Zeit scheint damit verbracht zu werden, mehr als 200 MB an Daten herunterzuladen, was angesichts der Tatsache, dass die gesamte numpy-Quelle 4 MB umfasst, ziemlich verwirrend ist. Selbst wenn dies sofort geschehen sollte, gibt es jedoch immer noch 25 Sekunden für die tatsächliche Verarbeitung, und selbst das scheint übertrieben, um ein paar Hashes zu berechnen. Das anschließende Sperren dauert auch nach dem Löschen von Pipenv.lock 5 s.

11:46 ~/Co/Ce/torchdft time pipenv install
Creating a virtualenv for this project…
Using /usr/local/Cellar/pipenv/2018.5.18/libexec/bin/python3.6 (3.6.5) to create virtualenv…
⠋Already using interpreter /usr/local/Cellar/pipenv/2018.5.18/libexec/bin/python3.6
Using real prefix '/usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6'
New python executable in /Users/hermann/.local/share/virtualenvs/torchdft-mABBUp_t/bin/python3.6
Also creating executable in /Users/hermann/.local/share/virtualenvs/torchdft-mABBUp_t/bin/python
Installing setuptools, pip, wheel...done.

Virtualenv location: /Users/hermann/.local/share/virtualenvs/torchdft-mABBUp_t
Creating a Pipfile for this project…
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Updated Pipfile.lock (ca72e7)!
Installing dependencies from Pipfile.lock (ca72e7)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 0/0 — 00:00:00
To activate this project's virtualenv, run the following:
 $ pipenv shell
        7.81 real         6.39 user         1.64 sys
11:46 ~/Co/Ce/torchdft time pipenv install numpy --skip-lock
Installing numpy…
Collecting numpy
  Using cached https://files.pythonhosted.org/packages/f6/cd/b2c50b5190b66c711c23ef23c41d450297eb5a54d2033f8dcb3b8b13ac85/numpy-1.14.5-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
Installing collected packages: numpy
Successfully installed numpy-1.14.5

Adding numpy to Pipfile's [packages]…
        4.97 real         2.88 user         1.81 sys
11:46 ~/Co/Ce/torchdft time pipenv lock --verbose
Locking [dev-packages] dependencies…
Using pip: -i https://pypi.org/simple

                          ROUND 1                           
Current constraints:

Finding the best candidates:

Finding secondary dependencies:
------------------------------------------------------------
Result of round 1: stable, done

Locking [packages] dependencies…
Using pip: -i https://pypi.org/simple

                          ROUND 1                           
Current constraints:
  numpy

Finding the best candidates:
  found candidate numpy==1.14.5 (constraint was <any>)

Finding secondary dependencies:
  numpy==1.14.5 not in cache, need to check index
  numpy==1.14.5             requires -
------------------------------------------------------------
Result of round 1: stable, done

Updated Pipfile.lock (4fccdf)!
      219.24 real        25.14 user         5.77 sys

Numpy sollte jetzt wesentlich schneller sein (ich habe Ihr Beispiel tatsächlich als Testfall verwendet!). Bei meinem letzten Test hatte ich es bei ~30s auf einem kalten Cache auf einer VM.

Können Sie Verbesserungen mit der neuesten Version bestätigen?

Bei mir hat es sich auch wesentlich verbessert. Ich sitze jetzt auf einer sehr schnellen Verbindung und hatte nur 14 s, aber das war, als der Download mit 30 MB/s lief. Was wird außer einer einzigen Kopie des Quellcodes von numpy heruntergeladen?

Ich denke, wir laden redundante Räder herunter (nicht sicher). Wir werten die Situation bereits aus.

Ich habe mein Pipfile.lock drastisch geändert, indem ich einige Änderungen deinstalliert habe und jetzt das Bereitstellen auf einem anderen Computer einfriert. Irgendeine spezielle Lösung dafür?

Es wird nicht empfohlen, Ihre Sperrdatei manuell zu bearbeiten. Ohne weitere Informationen ist keine Hilfe möglich. Bitte öffnen Sie eine separate Ausgabe.

Wenn Sie die Leistung von pipenv lock vergleichen möchten, sollten Sie versuchen, pytmx zu Ihren Abhängigkeiten hinzuzufügen ...
pipenv lock brauchte bei uns 1 Stunde oder länger (wir haben ein ziemlich langsames Internet), und nachdem wir pytmx entfernt hatten, waren wir auf etwa 5 Minuten heruntergekommen und endlich ist pipenv besser nutzbar.
Ich weiß, dass pytmx ein großes Paket ist, weil es eine große monolithische Bibliothek ist und von opengl/pygame und anderen verwandten Dingen abhängt, aber es sollte nicht 1 Stunde dauern, bis Pipenv gesperrt ist, egal wie groß das Paket ist

Bei mir dauert es keine Stunde

$ cat Pipfile
[packages]
pytmx = "*"

$ time pipenv lock --clear
Locking [dev-packages] dependencies...
Locking [packages] dependencies...
Updated Pipfile.lock (eb50ab)!

real    0m2.827s
user    0m2.287s
sys 0m0.390s

Außerdem ist PyTMX weniger als 20 kb auf PyPI und hat nur eine Abhängigkeit von sechs (was super klein ist), daher sollte das Netzwerken kein Problem sein. In Ihrer Umgebung passiert wahrscheinlich noch etwas.

du hast recht es ist kleiner als ich dachte es hängt nicht explizit von pygame und so ab, ich weiß nicht warum es dann so lange gedauert hat !
Ich werde versuchen, mehr Informationen zu finden, aber ich habe eine Top-CPU und SSD, daher denke ich immer noch, dass das Problem mit unserem langsamen Internet zusammenhängt

@techalchemy Ich habe die Datei nicht manuell bearbeitet. Ich habe viele Abhängigkeiten mit pipenv uninstall package_name deinstalliert und anschließend auf dem Server ausgeführt. Es blieb sehr lange im Sperrzustand.

Ich bin nicht daran interessiert, Energie für diese Diskussion mit zufälligen Aufnahmen im Dunkeln zu verschwenden. Bitte legen Sie einen reproduzierbaren Testfall vor.

Hier ist, was ich hoffe, ein reproduzierbarer Testfall
https://github.com/Mathspy/tic-tac-toe-NN/tree/ab6731d216c66f5e09a4dabbe383df6dc745ba18

Versuch zu tun
pipenv install
in diesem locklosen Repository haben bisher über 700 MB heruntergeladen, während es angezeigt wurde
Locking [packages] dependencies...

Werde gleich aufgeben und mit --skip-lock wiederholen, bis es behoben ist

Mir ist aufgefallen, dass lock wirklich langsam war und habe riesige Datenmengen von files.pythonhosted.org heruntergeladen, mehr als 800 MB für ein kleines Projekt, das von scipy flask usw.

Also habe ich die Anfragen an files.pythonhosted.org geschnüffelt und es stellte sich heraus, dass pip oder pipenv völlig unnötige Downloads durchführten, was lock schmerzhaft langsam macht.

Beispielsweise wurde dieselbe Version numpy mehrmals vollständig heruntergeladen. Und es hat Räder für Windows / Linux heruntergeladen, obwohl ich einen Mac verwendet habe.

Mein Setup:

$ pipenv --version
pipenv, version 2018.05.18

$ pip -V
pip 18.0 from /usr/local/lib/python2.7/site-packages/pip (python 2.7)

Sind hier zusätzliche Pipfiles für das Debugging hilfreich?

Höchstwahrscheinlich @AlJohri , auch alle Informationen über laufende Prozesse / Sperren / io würden helfen

Sitze hier schon seit ungefähr 5 Minuten fest. Dachte zuerst, es könnten irgendwelche Pip-Installationsprobleme sein und alles frisch über Homebrew neu installiert, aber immer noch das gleiche Problem. Irgendwelche Ideen warum?

Nach ca. 6 - 7 Minuten endlich fertig. Ziemlich neu in Python und Pipenv, daher wäre eine kleine Hilfestellung, wo man die notwendigen Dateien zum Debuggen findet, großartig! :)

Das ist ziemlich schlecht, so dass ich Angst habe, neue Python-Bibliotheken zu installieren oder vorhandene zu aktualisieren.

Nachdem ich mir einen der Talks des Erstellers angesehen hatte, entschied ich mich für pipenv . Aber es ist zu langsam.

Danke für Ihr aufschlussreiches Feedback.

@techalchemy Wenn ich etwas tun könnte, um dies zu beheben. Ich freue mich sehr, dazu beizutragen.

Mir ist aufgefallen, dass lock wirklich langsam war und habe riesige Datenmengen von files.pythonhosted.org heruntergeladen, mehr als 800 MB für ein kleines Projekt, das von scipy flask usw.

Ich habe den Verdacht, aber keinen schlüssigen Beweis, dass scipy mit sehr langen pipenv Sperrzeiten korreliert.

manchmal sehr schmerzhaft, ich installiere PyPDF2 und texttract; pipenv brauchte ~10 Minuten zum Sperren.

Die Langsamkeit von pipenv behindert den Entwicklungsprozess für uns wirklich. Ich rate jetzt jedem, bei pip + virtualenv zu bleiben, bis dieses Problem behoben ist.

Gibt es Neuigkeiten zu diesem Thema? Irgendeine Möglichkeit zu helfen?
Duplikat von https://github.com/pypa/pipenv/issues/1914

/edit: btw, warum aktualisiert pipenv install die Versionen in der Lockfile? o.Ò Ich habe es gerade nach einer Zeitüberschreitung beim Sperren ausgeführt und jetzt, wenn ich mir die neue Sperrdatei ansehe, sehe ich, dass Pandas von 0.23.4 auf 0.24.0 aktualisiert wurde, numpy von 0.16.0 auf 0.16.1, etc ... Didn Erwarte nicht, dass das passiert, es sei denn, ich habe pipenv update getan ...

Ich finde es installiert sich schnell und sperrt sich langsam, sobald Sie also die Nachricht Installation Succeeded , können Sie weiterarbeiten ... es sei denn, Sie möchten etwas anderes installieren ...

... oder die Sperrdatei in ein Repo verschieben müssen.

Sollte install sowieso eine Sperre ausführen, da lock bereits ein separater Befehl ist? In der Zwischenzeit sollte die Optionsbeschreibung install angeben, dass auch gesperrt wird, und vielleicht sogar --skip-lock empfehlen.

Wie wäre es außerdem mit dem Anheften dieses Problems?

Pipenv ist ein wirklich wunderbares Tool und ich habe es immer empfohlen, aber ein Projekt mit 8 Modulen kann nicht gesperrt werden ... es läuft einfach ab. Es scheint kein Interesse zu geben, dieses Problem zu lösen, und das ist sehr frustrierend. Ich habe gelesen, dass Sie jetzt Abhängigkeiten erhalten können, ohne von pypy herunterzuladen. Ist das eine Problemumgehung für dieses Problem? Ich sehe hier keine Diskussion über diese Option. Im Moment ist das Tool für meine Zwecke unbrauchbar.

pexpect.exceptions.TIMEOUT: <pexpect.popen_spawn.PopenSpawn object at 0x10e12e400> searcher: searcher_re: 0: re.compile('\n') <pexpect.popen_spawn.PopenSpawn object at 0x10e12e400> searcher: searcher_re: 0: re.compile('\n') pipenv lock -r 87.22s user 18.57s system 11% cpu 15:02.77 total

Inwiefern ist dies nicht die Hauptpriorität für dieses Projekt? Pipenv ist so langsam, dass es ziemlich unbrauchbar ist. Eine nicht nur in einigen seltenen Nebenanwendungsfällen ist immer super langsam.

Ohne zu viel darüber zu wissen, was unter der Haube vor sich geht, dachte ich, dass dies mit einem lokalen Cache des Abhängigkeitsgraphen gut gelöst werden könnte.

Denken Sie daran: wenn wir die Paket - Cache x-1.2.3 abhängt y>=3.4 , können wir vor Ort eine Menge Arbeit tun , die derzeit in der Download - Paketen einen nach dem anderen erledigt ist, erweitert sie und Überprüfung Abhängigkeiten . Die Phase lock wäre dann so einfach wie:

• Vergleichen Sie das Pipfile mit dem Cache und stellen Sie sicher, dass wir alles haben, was wir brauchen.
• Wenn nicht, laden Sie etwas Neues herunter und berechnen Sie dort Abhängigkeiten
  
  
  
  • Cache die Änderungen
  
  
• Installieren.

In jedem Fall wäre das erste Mal zwar langsam, aber nachfolgende Sperren wären schmerzlos, nicht wahr?

Ich habe mich gerade entschieden, pipenv anstelle von pip für ein kleines Projekt zu verwenden. Als erstes habe ich pipenv install -r requirements.txt . Es sperrt die Abhängigkeiten jetzt seit ungefähr 10 Minuten. Daher gehe ich zurück zu Pip.

Leute, dieses Problem kostet Sie viele Benutzer. Ich schlage vor, es schnell anzugehen.

In meinem Fall hängt der Server bei der Installation der Abhängigkeiten auf dem Server stundenlang. Ich verwende die AWS EC2-Instance t2.micro mit 1 GB RAM. So viel RAM reicht für eine einzelne Anwendung mit wenigen Abhängigkeiten, aber die Installation nimmt den gesamten Speicher in Anspruch und es gibt nur eine Möglichkeit, ihn durch Neustart des Servers zum Laufen zu bringen.

Dieses Problem ist so lange anhängig und es wurde keine Lösung dafür vorgenommen. Ich sehe, dass mehrere Probleme ohne Lösung geschlossen werden.

So ein schönes Werkzeug, das vernachlässigt wird. Ich werde mich von diesem Problem abmelden, da ich sehe, dass es nie gelöst wird. Werde an so etwas wie Conda festhalten oder es manuell mit virtualenv machen.

Ich schätze, ich werde https://github.com/sdispater/poetry eine Chance geben :|

Kann ein Admin diesen Thread bitte für Kommentare schließen? Es sieht so aus, als ob der Diskussion keine hilfreichen zusätzlichen Inhalte hinzugefügt werden.

Ich würde gerne ein Ticket abonnieren, das die Arbeit zur Behebung des Problems verfolgt.

Danke!

Ich vermute, dass 99% der Leute, die dieses Tool verwenden und sich über diesen Thread beschweren, Programmierer sind. Anstatt zu jammern, setzen Sie Ihre Zeit dort, wo Ihr Mund ist, und reichen Sie eine PR ein.

Hallo @idvorkin ,

Ich habe es einmal versucht.
Es dauerte Wochen, bis die triviale Lösung zusammengeführt wurde .
Vergleichen Sie einfach die Anzahl der Diskussionen mit der tatsächlichen Fixgröße.

Ich möchte definitiv keine weiteren Fixes für dieses Projekt einreichen.

Ihr Rat ist also nicht so praktikabel, wie Sie annehmen können.

@Jamim im Namen der vielen User (und ich vermute auch die Admins), danke für eure Beiträge. Ich habe Ihre PR gelesen und konnte die Frustration nachempfinden. Dem muss ich jedoch mit

Natürlich kümmern wir uns um die Bibliothek, die wir pflegen, aber ich würde sagen, dass die Formulierung wahrscheinlich nicht der effektivste Weg ist, um eine positive Interaktion zu erzielen.

Ich habe die Admins noch nie getroffen, aber wenn sie mir (und vielleicht dir) ähnlich sind, sind sie Menschen mit einem geschäftigen Leben, deren Leben voller Verpflichtungen ist, noch bevor sie Energie für dieses Projekt aufwenden können.

In ähnlicher Weise wette ich, wenn Sie (oder jemand anderes) das Leistungsproblem beheben würden, hätten Sie eine Menge Leute, die Ihnen helfen würden, es zu entwickeln, zu testen, zusammenzuführen oder, falls erforderlich (und ich bezweifle stark, dass dies der Fall wäre) eine Abzweigung zu erstellen .

Ich bin dankbar für die Zeit, die die Entwickler dieses Projekts dafür aufwenden, aber ich schlage vor, dass in Fettdruck gewarnt werden sollte, dass dieses Projekt direkt über den Benutzerstimmen in README.md noch nicht produktionsbereit ist irreführend, wertvolle Zeit damit zu verbringen, ihren aktuellen pip/virtualenv-Stack durch pipenv zu ersetzen, bis sie von diesem langsamen Sperren erfahren und verstehen, dass sie es nicht verwenden können.

bis sie von dieser langsamen Sperrung erfahren und verstehen, dass sie sie nicht verwenden können.

Obwohl ich mich sehr über eine Beschleunigung freuen würde, da sie in der Tat sehr langsam ist, besteht keine Notwendigkeit für eine solche Übertreibung.

Ich benutze pipenv jeden Tag gut. Die Workflow-Verbesserungen, die es bietet, überwiegen die gelegentliche Langsamkeit bei weitem. Sperren ist einfach nicht etwas, was ich die ganze Zeit mache, im Gegensatz zum Ausführen von Skripten zum Beispiel.

Wie oft sperren Sie, dass es tatsächlich so problematisch wird, dass Sie das Gefühl haben, dass Sie es nicht verwenden können? :offener Mund:

@bochecha meine Aussage mag Ihrer Meinung nach pipenv install <something> habe, musste ich lächerlich lange warten, zuerst dachte ich, es geht um Berechnungen etwas und es wird es für die Zukunft zwischenspeichern, da ich nicht glauben konnte, dass es ein Problem in einem angeblich produktionsbereiten Paketmanager ist. Nach der Installation von ~ I 10. Paket über sie begann die Suche und fand ich diesen Thread, ich entfernt Pipfile und Pipfile.lock und ging zurück zu meinem pip / virtualenv Workflow. Ich war versucht, Poesie auszuprobieren, aber ich konnte keine weitere Stunde riskieren.

Diese Dinge passieren zum Beispiel in der JS-Community, aber ich erwarte es nicht in der Python-Community, wir haben diese Art von Problemen in unserer Community nicht und wir sollten versuchen, es zu vermeiden, ein Haftungsausschluss in README.md kann vermeiden diese Unannehmlichkeiten, also habe ich es in meinem Kommentar vorgeschlagen. Es könnte mir heute Zeit sparen und ich denke, es wird anderen Neulingen Zeit sparen und sie werden keine schlechten Erfahrungen mit diesem Projekt machen, damit sie als potenzielle zukünftige Benutzer bleiben können.

Ich stimme Sassanh irgendwie zu. Nicht alle sind gleichermaßen von dem Problem betroffen, aber einige von uns waren ziemlich stark betroffen. Ich habe Open-Source-Projekte gemacht, die nicht wirklich voll funktionsfähig oder produktionsreif waren, und wenn dies der Fall war, habe ich einen Haftungsausschluss darauf gesetzt, damit ich nicht die Zeit der Leute verschwende, wenn sie nicht bereit für die Unebenheiten sind.

Ich bin nicht sauer auf die Leute, die an diesem Projekt arbeiten, aber ich bin ein bisschen sauer auf die Person, die öffentlich darüber gesprochen und es als großartiges Werkzeug mit 0 Haftungsausschluss verkauft hat. Infolgedessen verschwendete ich ziemlich viel meiner kostbaren Zeit damit, ein Tool zum Laufen zu bringen, in der Hoffnung, auf lange Sicht Zeit zu sparen, aber am Ende musste ich zurück zu pip und meinem eigenen Skript, weil pipenv nicht funktionierte in meiner Umgebung mit eingeschränkter Zeit und Bandbreite.

Jedes Mal, wenn ich pipenv install ausgeführt habe

Wussten Sie, dass pipenv install -r requirements.txt Ihr vorhandenes Projekt nur einmal sperren/installieren muss, wenn Sie versuchen, es in pipenv zu verschieben? Wenn Sie dies nicht tun, liegt das Problem möglicherweise in der Dokumentation?

Vor allem bin ich mir sicher, dass pipenv ein guter Ersatz für den pip/virtualenv-Workflow sein wird. Ich denke, wir alle wissen, dass wir es brauchen und ich denke, an dem Tag, an dem pipenv produktionsbereit ist, wird es für viele Leute/Projekte eine große Hilfe sein.

@bochecha wie ich erklärt habe, musste ich eine neuere Version eines Pakets installieren, einige README.md , zumindest sollte erwähnt werden, dass "jede Sperrung lange dauern kann gelöst" (wieder in Fettdruck und zusätzlich zu den Erfahrungsberichten), wenn Sie die Probleme ankündigen, bevor jemand davon betroffen ist, werden alle dankbar sein, wenn die Probleme andere betreffen und Sie sie nicht gewarnt haben, werden alle wütend.

Einverstanden. Ich fing an, mich mit Poesie zu befassen und obwohl ich pro Projekt einen anderen Benutzer zu meinem Betriebssystem hinzufügte, anstatt Pipenv wieder zu verwenden. Wenn es für gelegentliche Anwendungsfälle mit den Standardeinstellungen nicht gut funktioniert, ist es
Es ist ein super nützliches Werkzeug! Es gibt nur eine Sache, die es für mich super nutzlos macht. Und leider habe ich wenig Zeit, um etwas beizutragen :|

Sicher, es ist ärgerlich, auf eine Sperre zu warten, wenn während der Entwicklungssitzung mehrere Installationen durchgeführt werden müssen, aber dies kann verwaltet werden.

Wichtig ist, dass eine Sperrdatei generiert wird, bevor lokale Änderungen an das Repository übertragen werden. Ich verwende das Flag —skip-lock während der Entwicklungssitzungen mit Bedacht und pipenv lock einmal am Ende, bevor ich festschreibe.

Danke für das Projekt. Aber,
Die Verriegelung ist verrrrrrrrrrrrrrrrrrrrrrrrrrrry langsamwwwwwwwwwwwwwwwwwwwwwwwwwwwwww.

PIP_NO_CACHE_DIR=off
Diese Umgebung macht das Sperren schneller, wenn bereits ein Pip-Paket-Cache installiert ist.

Hallo @yssource und alle zusammen,

Danke für das Projekt. Aber,
Die Verriegelung ist verrrrrrrrrrrrrrrrrrrrrrrrrrrry langsamwwwwwwwwwwwwwwwwwwwwwwwwwwwwww.

Dieses Projekt scheint tot zu sein. Wenn Sie also das Geschwindigkeitsproblem beseitigen möchten, ziehen Sie eine Migration zu Poetry in Betracht, die erheblich schneller ist.

@Jamim , danke für den Vorschlag von Poesie. Persönlich bin ich aus irgendeinem Grund nicht darauf gestoßen. Nach dem Lesen der Readme-Datei scheint es einen Versuch wert. Es listet auch einige Vorteile gegenüber Pipenv auf (https://github.com/sdispater/poetry/#what-about-pipenv).

Abgesehen davon ist das Projekt tot zu sein, eine grobe Übertreibung, und wenn ich in der Rolle eines Pipenv-Autors wäre, würde ich es respektlos finden. Der Autor hat erst gestern im Themenbereich geantwortet. Es ist nur dieses Sperrproblem, das übersehen wird, wahrscheinlich weil es schwer zu beheben ist.

Um es festzuhalten, Poetry leidet auch unter Leistungsproblemen:
https://github.com/sdispater/poetry/issues/338

Ich habe bei all meinen Projekten das gleiche Problem.
Die Ursache scheint Pylint zu sein.
Pipenv (pip) kann es erfolgreich installieren, aber das Sperren dauert ewig!
pipenv, version 2018.11.26

djbrown@DESKTOP-65P6D75:~$ mkdir test
djbrown@DESKTOP-65P6D75:~$ cd test
djbrown@DESKTOP-65P6D75:~/test$ pipenv install --dev pylint --verbose
Creating a virtualenv for this project…
Pipfile: /home/djbrown/test/Pipfile
Using /usr/bin/python3 (3.6.9) to create virtualenv…
⠸ Creating virtual environment...Already using interpreter /usr/bin/python3
Using base prefix '/usr'
New python executable in /home/djbrown/.local/share/virtualenvs/test-PW-auWy_/bin/python3
Also creating executable in /home/djbrown/.local/share/virtualenvs/test-PW-auWy_/bin/python
Installing setuptools, pip, wheel...done.

✔ Successfully created virtual environment!
Virtualenv location: /home/djbrown/.local/share/virtualenvs/test-PW-auWy_
Creating a Pipfile for this project…
Installing pylint…
⠋ Installing...Installing 'pylint'
$ ['/home/djbrown/.local/share/virtualenvs/test-PW-auWy_/bin/pip', 'install', '--verbose', '--upgrade', 'pylint', '-i', 'https://pypi.org/simple']
Adding pylint to Pipfile's [dev-packages]…
✔ Installation Succeeded
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
⠇ Locking...

Ich habe viel von Pipenv gehört und es heute ausprobiert.
die verriegelung ist bei mir auch sehr langsam. Es ist schon ungefähr 2 Minuten her, immer noch am Verriegeln hängen geblieben.
Das Herunterladen ist ziemlich schnell, aber das Problem liegt beim Sperren.
Ist dieses Problem gelöst?
Ich verwende Pop os 19.10, pipenv, Version 11.9.0 von apt, Python 3.7.5.

Ich möchte auf diesen ausgezeichneten Kommentar von #1914 zum gleichen Thema https://github.com/pypa/pipenv/issues/1914#issuecomment -457965038 aufmerksam machen, der darauf hindeutet, dass das Herunterladen und Ausführen jeder Abhängigkeit nicht mehr erforderlich ist.

Ich frage mich, ob irgendwelche Entwickler zur Machbarkeit dieses Ansatzes Stellung nehmen könnten.

Mir ist aufgefallen, dass es tatsächlich schneller ist, die Umgebung zu entfernen und von Grund auf neu zu erstellen, um die Sperrdatei zu aktualisieren.
Dies gilt sowohl für die Ausführung von pipenv lock als auch für pipenv install some-package

Ich mag pipenv wirklich, aber nicht so sehr, wie ich meine Bandbreite und Zeit mag. Also löse ich das Problem mit:

$ pipenv --rm
$ virtualenv .
$ source bin/activate
$ # Create a requirement file (Cause pipenv lock -r > requirements.txt... you know!)
$ pip install -r requirement.txt

Wünsche den Entwicklern viel Glück...

@ravexina danke für den Vorschlag, ich werde es auf