Hmm, vielleicht brauchen wir einen Befehl, um alle in PyPI verfügbaren Paketversionen aufzulisten.
Was denkst du?

Wie:

$ pip list Django

1.2.4

1.2.3

1.2.2

1.2.1

1.2

1.1.3

1.1.2

1.0.4

$

Original Comment By: Hugo Lopes Tavares

ich mag diese Idee.

Original Comment By: CarlFK

Ich habe es gerade in meinem Fork implementiert. Ich möchte die Meinungen von Carljm, Jezdez und Ianb
vor dem Zusammenführen.

Überprüfen Sie es hier: https://bitbucket.org/hltbra/pip-list-
Befehl/Änderungssatz/e5c135a46204

Original Comment By: Hugo Lopes Tavares

Ich habe nicht tief darüber nachgedacht, aber es erscheint mir besser, das zu verbessern
"search"-Befehl, um auch Versionen aufzulisten (möglicherweise alle Versionen mit einem -v-Flag aufzulisten
oder so), anstatt einen neuen separaten Befehl hinzuzufügen. Diese Funktionalität
scheint logischerweise ein Teil der Suche zu sein.

Original Comment By: Carl Meyer

Ich wäre damit einverstanden, dies zur Suche hinzuzufügen, solange meine andere ER implementiert ist
auch, damit ich nicht (wirklich) 3000 Zeilen bekomme, wenn ich nach Djangos Versionen suche.
(es gibt über 1000 Treffer zu "pip search django" wegen all dem django-foo
Pakete. )

Original Comment By: CarlFK

Ich halte es für unnötig zu zeigen, welche Version solange installiert wäre
Es gibt eine Liste der verfügbaren Versionen, denn es ist einfach festzustellen, welche
das ist das neuste. Außerdem gibt es keinen Grund, ein neues Flag zu verwenden
ermöglichen die Ausgabe dieser Liste, da der Overhead gegen Null geht. Es ist
nur eine kleine Änderung:
https://bitbucket.org/jumpa/pip/changeset/62076643cf33

Original Comment By: jumpa

Hallo Carl, ich habe zwar über das Hinzufügen einer Option zum Suchbefehl nachgedacht, aber meine Befürchtung
Was ist mit dem Installationsbefehl passiert: Wenn Sie ein "Upgrade" durchführen möchten
Paket, müssen Sie die Option "installieren" verwenden - das ist seltsam, und das wissen wir.

Und wenn die meisten Leute denken, dass es besser ist, eine Suchoption hinzuzufügen, verstehe ich das auch nicht
viele Probleme mit der Verwendung von search --versions oder search -v.

Original Comment By: Hugo Lopes Tavares

Ich denke, dass die standardmäßige Auflistung aller verfügbaren Versionen zu ausführlich ist. Etwas
Pakete haben viele verfügbare Versionen auf pypi - zehn oder zwanzig sind keine Seltenheit
überhaupt. Standardmäßig wird die neueste Version und alle Versionen mit einem Flag aufgelistet
scheint vernünftig.

Und ich stimme CarlFK zu, dass wir auch Verbesserungen brauchen, um die Suche zu machen
leichter zu verengen. Das Problem dabei ist, dass wir davon abhängen, was uns die PyPI-API gibt,
Das ist nicht viel: Wir werden nicht das gesamte PyPI herunterladen und eine Regex erstellen
vor Ort suchen! Ich würde so etwas wie ein --exact-Flag bevorzugen, nach dem gesucht werden soll
Teil dieser Änderung, so dass man zB nach "--exact django" suchen kann und nur bekommt
django selbst in Ihrem Ergebnis.

Original Comment By: Carl Meyer

Hallo jumpa, Tolle Idee, die Versionen mit der von xmlrpc erhaltenen Version zu zeigen
Verbindung!

Ich habe den folgenden Ausschnitt erhalten, der nach pip sucht:

pip                       - pip installs packages.  Python packages.  An

easy_install-Ersatz (Versionen: 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)

Das wird eine so große Liste von Paketen mit vielen Versionen -
weil unsere Suche sich um Namen und Zusammenfassungen kümmert. Sollten wir uns darum kümmern?

Original Comment By: Hugo Lopes Tavares

Als Endbenutzer gefällt mir die Idee, einen separaten Listenbefehl zu haben*. Als Zeit
geht auf einen separaten Befehl, der möglicherweise einfacher isoliert zu ändern und zu verbessern ist. Zu
Um einen separaten Listenbefehl nützlicher zu machen, könnten Sie angeben, welche Version, wenn
beliebig, ist derzeit installiert.

pip list Django


1.2.4

1.2.3 installed

1.2.2

1.2.1

1.2

1.1.3

1.1.2

1.0.4

Hinweis: Viele beliebte Paketmanager wie YUM(RedHat), pkglist(BSD),
dpkg(Debain) stellt ein separates Listen-Flag oder einen separaten Befehl bereit.

Original Comment By: Kelsey Hightower

Carl, ich habe an einem anderen Tag über dieses Thema nachgedacht, und ich muss dem zustimmen
Kelsey: Ein weiterer Befehl ist nicht schlecht.

Stellen Sie sich vor, wir verwenden ein Flag, um anzuzeigen, dass ich nur diesen Paketnamen haben möchte, und
ein weiteres Flag, um anzuzeigen, dass ich alle verfügbaren Versionen abrufen möchte.

Es ist ein bisschen seltsam.

Versuchen wir es mal zu veranschaulichen:

$ pip search -v --exact Django

gegen

$ pip list Django

Kelseys Idee, anzuzeigen, welche Version installiert ist, verbessert nur die Liste
Befehl.

Original Comment By: Hugo Lopes Tavares

Ich habe die Änderungen im Suchbefehl vorgenommen.

Da der Suchbefehl bereits die installierte und neueste verfügbare Version anzeigt, ist es wahrscheinlich sinnvoller, den Suchbefehl zu erweitern, um auch alle verfügbaren Versionen aufzulisten.

Hier ist mein Änderungssatz: https://github.com/phuihock/pip/commit/46bad23b5bf31850a02803ea1ca18be5deca9db3

Wie ist der Stand damit? Kann man mit pip die neueste verfügbare Version auf PyPI sehen?

Ist dies bereits implementiert? Das quält mich jetzt seit etwa zwei Jahren und ich würde es gerne gelöst sehen.
Die eingeschränkte Suche kombiniert mit einem Flag für Versionen scheint eine sehr brauchbare Lösung zu sein.

Ich wollte hier nur hinzufügen, dass ich gerade auf diesen Thread gestoßen bin, als ich nach dem Anzeigen von Versionen gesucht habe installiert werden, inklusive Versionsinfo...

Ich habe _gerade_ festgestellt, dass diese Funktionalität immer noch nicht implementiert ist, nachdem mich ein Kollege danach gefragt hat. Gibt es Pläne, dass es in den kommenden Versionen von pip verfügbar sein wird?

Ich glaube, diese PR könnte relevant sein, daran wird gerade gearbeitet?

Vielleicht interessieren Sie sich auch für den Linuxconf 2014-Vortrag „Python Packaging 2.0: Playing Well With Others“ über die aktuelle Situation sowie die Zukunft der Python-Paketierung. Der Redner sagte (wenn ich das richtig verstanden habe), dass einige der Einschränkungen für Metadaten in pip eine Folge des Designs von PyPI sind, das ursprünglich auf CPAN basierte, und dass die Überarbeitung des Backends von PyPI (während es mit Tests kompatibel mit dem aktuellen bleibt) sollte die Situation verbessern. Er sprach hauptsächlich von „Systemintegratoren“, dh nachgelagerten Paketierern, aber ich denke, das würde Dinge wie dieses Problem beeinflussen und es einfacher machen, sie zu lösen.

+1.000.000

und wie ist es jetzt?

Gibt es eine Möglichkeit, die neueste Version anzuzeigen, ohne sie zu installieren?
Dieses Problem ist seit 2011 offen und der Patch, den ich oben gesehen habe, ist nur eine Zeile. :(

Dies scheint eine geringfügige Funktion zu sein, die aktiviert werden muss. Wie kann es an dieser Stelle keine Option geben, die apt-cache madison entspricht?

Ich würde wirklich gerne die neueste Version des PyPi-Pakets bei der Suche sehen. Eine exakte Übereinstimmung zu haben, funktioniert, aber ich verwende awk als Problemumgehung.

Das hat mich auch frustriert und als ich sah, dass es wenig bis gar keine Hoffnung darauf gibt, entschied ich, dass es meine Zeit wert sein könnte, eine Alternative zu schaffen. Neben diesem Problem habe ich einige andere angeforderte Funktionen implementiert (wie Regex-Suche und kolorierte Ausgabe usw.). Wenn Sie interessiert sind, können Sie es hier überprüfen

wget -qO- https://pypi.python.org/pypi/uWSGI | egrep -o "uwsgi-[0-9].[0-9].[0-9][0-9].tar.gz" | sortieren -u

wget -qO- https://pypi.python.org/pypi/uWSGI/json | grep '"version"'

@andreif Dies wird nicht immer die richtige Version finden (pip ignoriert Alphas, Betas, Veröffentlichungskandidaten usw., es sei denn, --pre wird bereitgestellt). Dies ist näher (aber auch keine Garantien):
wget -qO- https://pypi.python.org/pypi/uWSGI/json | grep -E ' {8}"[0-9."]*": \[' | sort -V | tail -n 1 | tr -d ' ":['

Ok, dann sollte die JSON-Antwort etwas wie "pre-version": "1.2.3a4" enthalten, damit man beide mit einem einfachen Ausdruck erfassen kann.

Ich verstehe dieses Problem nicht wirklich ... Worum geht es?

• Hinzufügen einer neuen Option zu pip install , die Pip nur bis zur Auflösung der Pakete ausführen und die ausgewählten Pakete drucken und beenden würde (Installation überspringen)?
• Wird die neueste Version neben den Paketnamen angezeigt, wenn pip search verwendet wird?
  
  
  
  • Können Sie die neueste Version eines Pakets auf PyPI sehen?
  
  

Letzteres scheint mir gelöst zu sein und ersteres sollte wohl eine neue dedizierte Ausgabe bekommen.

@pradyunsg Nun, wenn ich mich richtig erinnere, brauchte ich eine einfache Möglichkeit, um zu überprüfen, welche Version derzeit verfügbar ist (sowohl Release als auch Vorabversion). Diese Version wird von pip install -U [--pre] installiert.

Ich brauchte es für ein Skript zum Einrichten einer virtuellen Umgebung. Wenn es eine neuere Version eines Pakets gab, wurde gefragt, ob die aktuelle Version aktualisiert oder beibehalten werden soll. Dieser Anwendungsfall wird also von der neuen Pip-Suche abgedeckt.

pkg="foo"; pip install --download /dev/null --no-cache-dir --no-binary :all: "$pkg" 2>&1 | egrep -i "$pkg"'-' | head -1 | egrep -io "$pkg"'-[^ ]+' | sed 's/^'"$pkg"'-\(.*\)\.tar\.gz$/\1/g'

Poste --download -veraltete Version...

pkg="foo"; tmp="$(mktemp -d)"; pip download -d "$tmp" --no-cache-dir --no-binary :all: "$pkg" 2>&1 | egrep -i "$pkg"'-' | head -1 | egrep -io "$pkg"'-[^ ]+' | tr A-Z a-z | sed 's/^'"$pkg"'-\(.*\)\.tar\.gz$/\1/g'

Verwenden Sie etwas wie:

pip install foo==

gibt eine Liste aller verfügbaren Versionen (für ein gültiges pypi verfügbares Paket, in diesem Fall Molekül):

Could not find a version that satisfies the requirement molecule== (from versions: 1.20.1, 1.20.3, 1.21.1, 1.22.0, 1.23.0, 1.25.0, 1.25.1, 2.10.0, 2.10.1, 2.11.0, 2.12.0, 2.12.1, 2.13.0, 2.13.1, 2.14.0, 2.15.0, 2.16.0, 2.17.0, 2.18.0, 2.18.1, 2.19.0) No matching distribution found for molecule==

aber es wäre schön, die Version zu bekommen, die mit pip installiert würde, ohne sie tatsächlich herunterzuladen und/oder auf dev/null zu installieren :-)

Einverstanden. Ein Paketmanager ohne diese Funktionalität ist ein Witz. Sogar Ihr Beispiel, eine Versionsliste zu erhalten, ist ein vollständiger Hack, um eine weitere Funktion zu kompensieren, die dieser Paketmanager nicht hat. Ich sage das nicht gemein, aber das sind Dinge, die vor acht Jahren hätten verfügbar sein sollen, als genau dieser Fehler, der völlig ignoriert wird, erstellt wurde. Ich nehme an, Pip wird einfach durch etwas ersetzt, das tatsächlich mehr Funktionen hat, aber auch abscheulich, grotesk, ungeheuer groß und überkompliziert ist. Na ja, wir können immer unsere eigenen schreiben.

pip-tools ist ein auf pip basierendes Tool, von dem ich glaube, dass es bei einigen Dingen helfen kann, nach denen die Leute in diesem Thread fragen: https://github.com/jazzband/pip-tools

Wenn Sie ihm eine Liste abstrakter Abhängigkeiten geben (dh ohne Angabe von Versionen), wird es Ihnen die spezifischen Versionen jeder zu installierenden Anforderung und Abhängigkeit mitteilen.

pkg="django"; echo "$pkg" | pip-compile - --output-file - | egrep -i '^'"$pkg"'=' | cut -d '=' -f 3- ist genauso albern (noch alberner, wenn man bedenkt, dass es eine andere Sache ist, die man installieren muss [noch alberner, wenn man Python2-Unterstützung braucht])

Darüber hinaus kann der ganze Sinn von pip-tools (& pipenv) mit einfachem pip und einer Constraints-Datei erreicht werden. ( pip install -r reqs -c constraints; pip freeze > constraints ).

Hinzufügen einer neuen Option zu pip install , die Pip nur bis zur Auflösung der Pakete ausführen und die ausgewählten Pakete drucken und beenden würde (Installation überspringen)?

Ich habe hier gerade einige wichtige Haushaltsarbeiten durchgeführt, und dieses Problem dient jetzt dazu, diesen Anwendungsfall zu verfolgen / zu diskutieren + ob / wie sich pip ändern würde, um dieser Anforderung nach neuen Funktionen gerecht zu werden.

Ich habe eine ganze Reihe von Kommentaren ausgeblendet, angefangen von wirklich alten Kommentaren, denen der relevante Kontext nicht mehr beigefügt ist, bis hin zu solchen, die „potenzielle Hacks/Skript-Nuggets“ enthielten, um 90 % der Arbeit dafür zu erledigen. Für die letztere Gruppe sehen Sie bitte davon ab, mehr davon hier zu posten – es gibt andere Benutzer-Support-Foren, in denen diese Vorschläge besser geeignet wären, nicht im Forum, in dem diskutiert wird, wie der Fix im Tool selbst implementiert werden kann. :)

Entschuldigung an alle, deren eigentlich immer noch relevanter und nützlicher Kommentar ausgeblendet wurde; Ich konnte wirklich den Kontext für viele Kommentare nicht herausfinden, und Ihre wurden möglicherweise nur in Kollateralschäden versteckt.

Da dieses Ticket durch die Entwicklung des Dependency-Resolvers (#988) blockiert wird, dachte ich, ich würde hier erwähnen, dass das Team Hilfe von der Community sucht, um dieses Thema voranzutreiben.

Wir müssen die Umstände besser verstehen, unter denen der neue Resolver fehlschlägt, also bitten wir Pip-Benutzer mit komplexen Abhängigkeiten um Folgendes:

1. Probieren Sie den neuen Resolver aus (verwenden Sie Version 20.1, führen Sie --unstable-feature=resolver aus)
2. Mach Schluss :P
3. Melden Sie ein Problem

Weitere Informationen und ausführlichere Anleitungen finden Sie hier

Ein Anwendungsfall, den ich hervorheben möchte, der sich aus Experimenten in #7819 ergeben hat und den ich in diesem Thread noch nicht erwähnt sehe, ist speziell das Aufzeichnen von URLs für das spätere Herunterladen und Installieren von Paketen , was eine leicht orthogonale Funktionalität zu den oben besprochenen Sperrdateien ist, und ist besonders nützlich, um die Ergebnisse einer Pip-Auflösung zu konsumieren, ohne große Dateien herunterladen zu müssen.

Wir haben bei Twitter eine Paketierungsmethode für große, typische Anwendungen für maschinelles Lernen entwickelt, die wir „ipex“ nennen und die ausgeliefert werden können, ohne Code von Drittanbietern zu enthalten, bis sie zum ersten Mal ausgeführt werden (was ihre Größe stark reduziert). Im Fall von pantsbuild/pants#8793 generieren wir ein ausführbares PEX-Archiv, das die PEX-Laufzeitbibliothek aufruft, um Anforderungen zu lösen (PEX führt pip unter der Decke aus). Ich arbeite derzeit an einem Prototyp, der den vollständigen PEX/PIP-Auflösungsschritt zur Laufzeit durch einen Ersatz ersetzt, der nur die URLs aufzeichnet, von denen Dists heruntergeladen werden sollen (die req.link ). Das geht in der Praxis extrem schnell (und kann sehr granular zwischengespeichert werden), da der Download und das Kopieren der Dateien zum Erstellen der „hydratisierten“ PEX-Datei komplett parallel erfolgen können.

Diese Fähigkeit (das parallele Herunterladen und Installieren von Tonnen von Rädern/Nicht-Rädern) beruht darauf, dass zusätzlich nur die URL von Rädern oder Nicht-Rädern offengelegt wird, die wir in eine Sperrdatei einfügen würden, die ich hier noch nicht erwähnt sehe. Dadurch kann pants pip genau einmal aufrufen (um Download-URLs aufzulösen), wenn eine dehydrierte ipex-Datei erstellt wird, und dann kann das Ergebnis dieses „Auflösen“-Schritts mit URLs verwendet werden, um Anforderungen herunterzuladen, wenn die ipex-Datei zum ersten Mal vollständig aufgerufen wird andere Maschine, ohne pip erneut aufrufen zu müssen.

In #7819 war viel Aufwand erforderlich, um die URLs aus den Eingeweiden des v1-Resolvers an die Ausgabe zu propagieren. Es war viel weniger Aufwand, als ich zuletzt versuchte, es mit dem v2-Resolver zum Laufen zu bringen. Im Moment planen wir wahrscheinlich, eine experimentelle Version eines --dry-run - oder resolve -Befehls intern auszuliefern, der Download-URLs ausspuckt -- wenn uns das gelingt, sollte das hoffentlich dabei helfen, welche zu finden verbleibende Ausgaben mit --unstable-feature=resolver in der Zwischenzeit! :D:D

Wie Sie bereits erwähnt haben, ist das Design des Sperrdateiformats orthogonal zur Resolver-Implementierung. Dies bedeutet jedoch auch, dass es für das aktuelle Pip-Projekt nicht in Frage kommt. Es gab Diskussionen zu dem Thema (Achtung: sehr langer Thread), aber angesichts des Mangels an verfügbarer Entwicklerzeit bedeutet dies wiederum, dass ernsthafte Diskussionen wahrscheinlich nicht stattfinden werden, bevor der Resolver zumindest stabilisiert ist.

Danke für den Link!!

Am Sonntag, 24. Mai 2020 um 19:34 Uhr Tzu-ping Chung [email protected]
schrieb:

Wie Sie bereits erwähnt haben, ist das Design des Sperrdateiformats orthogonal zum
Resolver-Implementierung. Dies bedeutet jedoch auch, dass es außerhalb des Geltungsbereichs von liegt
aktuelles Pip-Projekt. Es gab Diskussionen zu dem Thema
https://discuss.python.org/t/structured-exchangeable-lock-file-format-requirements-txt-2-0/876/1
(Achtung: sehr langer Thread), aber in Anbetracht der fehlenden Entwicklerzeit
verfügbar, was wiederum bedeutet, dass eine ernsthafte Diskussion wahrscheinlich nicht stattfinden wird
passieren, bevor der Resolver zumindest stabilisiert ist.

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/pypa/pip/issues/53#issuecomment-633346918 oder
Abmelden
https://github.com/notifications/unsubscribe-auth/AAJ6UT3IK65CUQGUIOGBNVDRTHKMVANCNFSM4AIQRXLA
.

@cosmicexplorer Hast du diese experimentelle Version eines --dry-run - oder resolve -Befehls schon intern ausgeliefert? Wenn ja, wie geht es weiter?

Ihr habt vielleicht bemerkt, dass ich mich sehr für dieses Feature interessiere 😄

Verwenden Sie etwas wie:

pip install foo==

gibt eine Liste aller verfügbaren Versionen (für ein gültiges pypi verfügbares Paket, in diesem Fall Molekül):

Could not find a version that satisfies the requirement molecule== (from versions: 1.20.1, 1.20.3, 1.21.1, 1.22.0, 1.23.0, 1.25.0, 1.25.1, 2.10.0, 2.10.1, 2.11.0, 2.12.0, 2.12.1, 2.13.0, 2.13.1, 2.14.0, 2.15.0, 2.16.0, 2.17.0, 2.18.0, 2.18.1, 2.19.0) No matching distribution found for molecule==

aber es wäre schön, die Version zu bekommen, die mit pip installiert würde, ohne sie tatsächlich herunterzuladen und/oder auf dev/null zu installieren :-)

Guter Trick !! Nützlich und bequem !! Sehr beeindruckend !!

potenzielle Hacks/Scripting-Nuggets ... bitte posten Sie nicht mehr von letzterem hier -- es gibt andere Benutzer-Support-Foren, in denen diese Vorschläge besser geeignet wären, nicht im Forum, in dem diskutiert wird, wie der Fix im Tool selbst implementiert werden kann. :)

Wirklich nicht umsonst, aber so etwas passiert, wenn man einen Fehler sehr lange verweilen lässt (7,56 Jahre im Fall meines eigenen zuletzt beigesteuerten "Nuggets", obwohl dieser noch offene Fehler jetzt 9,25 Jahre beträgt alt). Die Leute teilen ihre Problemumgehungen.

Ich bezweifle auch, dass das Ausblenden von Kommentaren einschließlich Problemumgehungen den Leuten hilft zu erkennen, dass die Problemumgehung, die sie in einem Kommentar posten, unnötig ist (teilweise, weil niemand auf all diese versteckten Kommentare klicken wird, um zu sehen, was bereits gesagt wurde). Wenn jemand auf einen jahrzehntealten Fehler stößt und keinen Fortschritt oder keine Richtung von den Betreuern oder eine Problemumgehung findet, wage ich zu sagen, dass er es als notwendig erachtet, eine Problemumgehung zu teilen, weil andere Menschen durch Ihre Arbeit leiden müssen hab schon selber gemacht ist unnötig.

Und ja, genau dieser Kommentar passiert auch, wenn das passiert, was Sie als Reaktion auf diesen noch offenen Fehler getan haben.

Keine Sorge, ich für meinen Teil werde keine unprovozierten Kommentare mehr hinzufügen, es sei denn, Pip bricht mein Skript erneut und dieser Fehler ist noch offen.

Danke für das, was Sie tun. :)

@brainwane @ei8fdb Ich möchte dieses Problem aus UX-Perspektive als wichtig kennzeichnen – bezogen auf #8377

Zusammenfassung auf hohem Niveau basierend auf meinem Verständnis:

• mit dem neuen Resolver wird pip weniger freizügig sein und sich weigern, widersprüchliche Abhängigkeiten zu installieren ( ResolutionImpossible )
• Abhängigkeitskonflikte können überall im Abhängigkeitsbaum bestehen
• Bestehende Tools (pipdeptree pip-conflict-checker) zeigen nur Pakete, die bereits installiert sind, nicht die, die angefordert wurden, aber fehlgeschlagen sind
• Derzeit gibt es keine Möglichkeit für Benutzer, herauszufinden, wo der Abhängigkeitskonflikt liegt, _bevor_ ein Paket installiert wird oder wenn ein ResolutionImpossible -Fehler auftritt (anders als die Abhängigkeiten jedes Projekts manuell zu überprüfen).

Kurz gesagt, wir brauchen eine Möglichkeit für Benutzer, mögliche Abhängigkeitskonflikte basierend auf ihren Anforderungen auf oberster Ebene (dh den in requirements.txt angegebenen oder direkt in die Befehlszeile eingegebenen Paketen) zu erkennen.

Wenn wir uns dazu entschließen, sollte der vorgeschlagene Flaggenname ( --dry-run ) recherchiert/diskutiert werden.

@uranusjr @pfmoore – bitte korrigiere mich, wenn ich aufgrund unserer Diskussion etwas falsch gemacht oder etwas übersehen habe. Vielen Dank

@nlhkabu Ich stimme all Ihren obigen Kommentaren zu. Um es jedoch klarzustellen: Ein --dry-run -Befehlsstil ermöglicht es Benutzern, zu überprüfen, ob es einen Abhängigkeitskonflikt geben wird. Aber wie beschrieben, bietet es keine zusätzliche Hilfe bei der Diagnose, warum der Konflikt besteht. Es ist also im Grunde ein "Schauen, bevor du springst"-Installationsbefehl, im Gegensatz zum normalen "Bitte um Verzeihung"-Ansatz, bei dem wir installieren, wenn wir können, aber nichts tun und den Fehler melden, wenn nicht.

Was dies nicht bietet und was meiner Meinung nach sehr nützlich wäre (entweder als Pip-Unterbefehl oder genauso nützlich wie ein Drittanbieter-Tool), ist eine Möglichkeit, aufzulisten, wie der Abhängigkeitsbaum aussieht, mit dem Pip arbeitet . (Dies erfordert keinen Resolver oder einen tatsächlichen Installationsschritt, es listet „einfach“ transitiv die Abhängigkeitsmetadaten aus den Paketquellen auf).

Dies könnte auch in Form eines pip resolve -Befehls erfolgen.

pip resolve ist das, was die meisten erwarten würden, bitte nennen Sie es so 😄 Es würde schließlich auch seine eigenen Flaggen zulassen.

Danke für die Klarstellung @pfmoore. Aus Benutzersicht bin ich mir nicht sicher, wie viel Nutzen --dry-run ohne resolve hat?

Meiner Meinung nach reicht es nicht aus, den Benutzern zu sagen, dass sie einen Fehler erhalten werden – wir müssen ihnen auch genügend Informationen geben, um herauszufinden, wo es ist, und etwas dagegen zu unternehmen.

Stellen Sie sich also vor, ein Benutzer führt --dry-run aus ... wir könnten so etwas in die Antwort aufnehmen:

Abhängigkeitskonflikt erkannt. pip kann d 1.0 und c 1.0 nicht installieren.
Der Konflikt wird verursacht durch:
d 1,0 hängt von E==2,0 ab
c 1,0 hängt von E==1,0 ab
Führen Sie pip resolve aus, um den Abhängigkeitsbaum zu untersuchen.

Wir könnten auch pip resolve in der Fehlermeldung ResolutionImpossible wiederverwenden (siehe #8377), was ein großer Gewinn wäre.

@pradyunsg haben wir ein separates Ticket für pip resolve ?

@nlhkabu https://github.com/pypa/pip/issues/7819

Nur um das klarzustellen, ich glaube, der beabsichtigte Anwendungsfall für pip resolve ist einer von beiden (unter der Annahme von Erfolg):

1. Leiten Sie die Ausgabe in eine Datei um (die normalerweise festgeschrieben wird), oder
2. andere Tools verwenden/parsen die Ausgabe

Für Twitter erstellen wir mit dem „ipex“-Tool, wie in #7819 beschrieben, ausführbare PEX-Dateien mit einem pip resolve -Befehl, der Download-URLs für alle aufgelösten Distributionen ausgibt, anstatt etwas herunterzuladen (wird noch nicht in der Produktion verwendet ). Zusammen mit mehreren anderen Optimierungen, zB #8448, ermöglicht dies das Erstellen dieser IPEX-Dateien innerhalb von Sekunden. Diese ipex-Dateien laden dann alle Distributionsausgaben des pip resolve -Befehls herunter, wenn sie zum ersten Mal ausgeführt werden, aus demselben Rechenzentrum – dadurch können die ipex-Dateien selbst Megabyte statt Gigabyte groß sein, was die Upload-Zeit verkürzt aus vielen Regionen.

Also betten wir im Grunde genommen eine JSON-Version der pip resolve -Ausgabe als Datei in das PEX-Archiv ein, und wir haben ein Bootstrap-Skript, das das liest, um die Distributionen parallel herunterzuladen.

Gibt es hierzu Neuigkeiten?

Jemand muss zuerst herausfinden, wie das Auflösungsergebnis präsentiert wird. AFAIK-Pip-Betreuer, die an Resolver-Arbeiten beteiligt sind, unternehmen derzeit alle Anstrengungen, um den Resolver selbst zu verbessern, sodass dies etwas Hilfe von außen erfordern würde, um voranzukommen.

Bitte korrigieren Sie mich, wenn ich falsch liege, aber das Folgende scheint wahr zu sein:

• Die Installation eines Python-Pakets beinhaltet die Ausführung seiner setup.py.
• Ohne eine --dry-run -Option gibt es keinen einfachen und zuverlässigen Weg, um zu wissen, welche Pakete der Resolver von pip installieren wird.

Daher scheint es mir, dass das Ausführen pip install bedeutet, der Ausführung von Code aus einer ziemlich willkürlichen Auswahl von PyPI-Paketen auf dem eigenen Computer zuzustimmen, ohne eine einfache und zuverlässige Möglichkeit, ihn zu prüfen. Diese Auswahl hängt rekursiv von den Abhängigkeitsentscheidungen und Sicherheitspraktiken der einzelnen Paketautoren ab.

Es hängt davon ab, ob das zu installierende Projekt und Version nur eine Quelldistribution (sdist, enthält setup.py) oder auch Wheels (gebaute Distribution, enthält eine Metadaten-Textdatei, wird durch Dateikopien installiert, ohne dass beliebiger Code ausgeführt wird)

Selbst mit --dry-run ist es wahrscheinlich, dass pip Build-Backends für die Pakete ausführen muss (was für setuptools das Ausführen von setup.py beinhaltet), die keine Räder haben.