Pipenv: Aktualisieren nur einer gesperrten Abhängigkeit

Das kann auch für pipenv install nützlich sein, da ich manchmal eine neue Abhängigkeit installieren möchte, ohne andere zu aktualisieren.

Hier ist eine Kleinigkeit zu beachten: Durch Ändern einer einzelnen Abhängigkeit können sich die allgemeinen Anforderungen ändern.
Beispiel: Für das Aktualisieren von foo von 1.0 auf 2.0 muss möglicherweise bar auf> = 2.0 aktualisiert werden (während es zuvor <2.0 war) und so weiter.

Ich weiß, dass im Kontext von pip-tools selbst (von dem pipenv seinen Algorithmus für die Abhängigkeitsauflösung übernimmt) das Ausführen der Abhängigkeitsauflösung die erforderlichen Pakete nur "aktualisiert", wenn sie erneut gesperrt werden, wenn dies der Fall ist eine vorhandene Sperrdatei. Dazu wird zuerst geprüft, ob die vorhandenen Pins in der Sperrdatei ein gültiger Kandidat sind, wenn ein Kandidat in der Auflösung ausgewählt wird. pipenv könnte wahrscheinlich dasselbe tun.

Ich denke, es ist eine vernünftige Idee. Wenn Sie andernfalls nur eine Abhängigkeit aktualisieren möchten, muss pipenv einen zu blockierenden Modus haben, wenn das Ändern einer Abhängigkeit andere Änderungen verursacht. Andernfalls verlieren Sie die Garantie einer gültigen Umgebung.

Ich hoffe das hilft!

In der Tat meinte ich damit:

Das würde ein Pipfile.lock mit Updates nur für my-awesome-dep und seine Abhängigkeiten erzeugen.

Stimmen Sie 100% zu - und ich gehe noch ein bisschen weiter: Dies sollte die Standardeinstellung sein.

Das heißt, pipenv install foo sollte niemals etwas anderes berühren als foo und seine Abhängigkeiten. Und pipenv lock sollte auf keinen Fall etwas aktualisieren - es sollte nur das sperren, was bereits installiert ist.

AFAICT, so funktionieren npm , yarn , gem usw.; Es macht keinen Sinn, eine Sperrdatei zu haben, die Pakete nicht wirklich sperrt, aber den Paketautoren vertraut, dass sie in Patch-Releases keine Probleme verursachen und sie daher ohne Aufforderung aktualisieren. Ich kann sehen, wie man Upgrades zulässt, aber das sollte aktiviert sein, da es überraschender ist, als sie nicht zu aktualisieren.

Ich entschuldige mich, wenn ich dieses Problem für etwas anderes entführe, aber da dies so eng mit einem Problem zusammenhängt, das ich gerade erstellen wollte, dachte ich, ich würde das Gespräch hier beginnen. Fühlen Sie sich frei, mir zu sagen, ich sollte einen neuen machen.

Ich habe gerade auch dieses Problem gefunden: https://github.com/kennethreitz/pipenv/issues/418

In der Lage zu sein, pipenv install --upgrade-strategy=only-if-needed anzugeben, scheint das zu sein, wonach ich suche, obwohl ich natürlich, wie bereits erwähnt, der Standard sein sollte, da es in Pip 10 wird. Aber in der Lage zu sein, es semi-permanent über anzugeben env var wäre sowieso etwas.

Es würde mich wundern, wenn diese Änderung den Workflow eines Menschen unterbricht ( berühmte letzte Worte ), da sie konservativer ist als --upgrade-strategy=eager .

Es wurde versucht, dies zu umgehen, indem in meiner Shell-Konfiguration export PIP_UPGRADE_STRATEGY=only-if-needed wurde. Dies funktioniert nicht und pipenv lock zeigt diese überraschenden Verhaltensweisen:

1. Es "aktualisiert" Pakete, die nicht aktualisiert werden müssen (aber ...)
2. Die installierten Versionen werden tatsächlich nicht aktualisiert! dh pip freeze und Pipfile.lock zeigen verschiedene Versionen!

Vermutung, dass pipenv für die Installation an pip delegiert, und pip respektiert die Einstellungen der Umgebungsvariablen, pipenv lock jedoch nicht.

@ k4nar Was passiert gerade, wenn Sie unerwünscht finden? Denn wenn Sie eine Abhängigkeit aktualisieren, für die Kaskadenanforderungen gelten, hat dies offensichtlich Konsequenzen für andere Abhängigkeiten. Schlagen Sie eine Art Resolver-Logik vor, um die aktuellste Version eines bestimmten Pakets im Kontext der aktuellen Sperrdatei zu ermitteln? Ich zögere, zu viele Hacks zur Auflösungslogik zu ermutigen, die bereits kompliziert und schwer zu debuggen ist.

@brettdh Ich denke, ich kann etwas Licht ins Dunkel bringen, weil du die meisten Stücke hast. pipenv lock installiert nichts und erhebt keinen Anspruch darauf. Es wird nur die Sperrdatei generiert, die Ihrer Host-Umgebung, der Python-Version und einem bereitgestellten Pipfile . Wenn Sie Ihre Umgebung auf eine andere Weise manipulieren oder wenn Sie pip direkt verwenden / pip-Einstellungen außerhalb von pipenv bearbeiten / nicht pipenv run oder pip freeze in einer pipenv-Subshell verwenden, ist dies recht einfach Eine Sperrdatei, die von pip freeze nicht mehr synchron ist. Die beiden sind nicht wirklich verwandt.

Deutlich sein:

1. Pipfile.lock ist eine streng festgelegte Abhängigkeitsauflösung unter Verwendung des Pip-Tools-Resolvers, der auf dem Pipfile des Benutzers basiert
2. Wenn Sie strenge Pins von allem beibehalten möchten, während Sie nur ein Paket aktualisieren, können Sie dies meiner Meinung nach tun, indem Sie alles in Ihrem Pipfile streng fixieren,

Was Ihre Sperrdatei und pip freeze betrifft, die nicht miteinander übereinstimmen, müsste ich weitere Informationen wissen, aber ich glaube, wir haben ein offenes Problem bezüglich unseres Sperrdateiauflösers, wenn wir Nicht-Systemversionen von Python zum Auflösen verwenden.

@techalchemy : Wenn ich ein Pipfile.lock mit A, B und C habe, wobei B eine Abhängigkeit von A ist, möchte ich A und B aktualisieren können, ohne C zu aktualisieren, oder C, ohne A und B zu aktualisieren.
Natürlich kann ich auch hier alle meine Abhängigkeiten und ihre Abhängigkeiten in meiner Pipfile anheften, um dies zu tun, aber das wäre eine Belastung (wie die meisten requirements.txt ).

Ich stimme mit allem überein, was @ k4nar geschrieben hat. Klar, ich könnte sogar einfach pinnen
alles in der anforderung.txt und nicht pipenv verwenden. Der Punkt von pipenv ist
ein Tool zu haben, das das macht (und das virtuelle Zeug natürlich)
einfacher zu verwalten; dh alle Pakete sind standardmäßig an eine Version gebunden
Das funktioniert bekanntermaßen, aber es sollte einfach sein, eine Auswahl zu aktualisieren
wenige (ohne andere unerwartet zu aktualisieren).
Am Donnerstag, 26. Oktober 2017, um 04:28 Uhr Yannick PÉROUX [email protected]
schrieb:

@techalchemy https://github.com/techalchemy : Wenn ich ein Pipfile.lock habe
mit A, B und C, wobei B eine Abhängigkeit von A ist, würde ich gerne dazu in der Lage sein
Aktualisieren Sie A und B, ohne C zu aktualisieren, oder C, ohne A und B zu aktualisieren.
Auch hier kann ich natürlich alle meine Abhängigkeiten und ihre Abhängigkeiten in meine stecken
Pipfile, um das zu tun, aber das wäre eine Belastung zu pflegen (wie
Die meisten Anforderungen.txt sind).

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/kennethreitz/pipenv/issues/966#issuecomment-339591307 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AAFlnqUOEKARiFD8kEk3GVczF3NXBdVOks5swEKcgaJpZM4QEf--
.

Hm ich verstehe was ihr sagt. Die Prämisse, eine Einstellung an pip zu übergeben, ist nicht das, worüber ich mir Sorgen mache, sondern die Lösung mit Pip-Tools, die mich betreffen. Wie sieht dieses Verhalten jetzt aus?

@techalchemy Ich erwähnte den Unterschied von pip freeze als Abkürzung für "Die Paketversionen, die pipenv install installiert, unterscheiden sich von den Paketversionen, die pipenv lock auf Pipfile.lock spart."

Dies geschieht zwar nur, wenn ich die Standardargumente von pip über die Umgebungsvariable geändert habe. Ich habe nur darauf hingewiesen, dass es überraschend ist, dass pipenv zur Installation an pip delegiert wurde, nicht jedoch zur Versionssperre. dh anstatt Verriegelung , was installiert ist, es sperrt , was es denkt , dass installiert werden soll, möglicherweise mit unaufgeforderten Upgrades.

Könnten Sie Ihre Frage etwas klären? Ich denke, "Auflösen mit Pip-Tools" bezieht sich auf das, was pipenv lock tut, und den Grund, warum es nicht beeinflusst wird, wenn ich Pip-Standardeinstellungen festlege? Und könnten Sie genauer sagen, was Sie unter "diesem Verhalten" verstehen?

@brettdh Der pip nicht vorhanden ist. Es wird von pip-tools (oder besser gesagt, eine gepatchte Version davon, die auf besondere Weise von pipenv wurde und einige Unterschiede zum ursprünglichen Tool mit sich bringt). Kurz gesagt, der Sperrmechanismus liest die Pipfile und führt eine vollständige Abhängigkeitsauflösung durch, um einen vollständigen Satz von Paketen auszuwählen, der alle durch die erforderlichen Pakete und ihre Abhängigkeiten definierten Einschränkungen erfüllt.

@ Techalchemy

[...] es löst sich mit Pip-Tools, die mich betreffen.

Ich bin mir nicht sicher, wie sich diese --upgrade-strategy auf pip-tools auswirken würden, da dies bei einigen Low-Level-Interna von pip funktioniert. Ich habe das Gefühl, dass dies nicht das erwartete Ergebnis liefern würde, da diese Option berücksichtigt, was installiert ist, und das ist nicht das, was in diesem Mechanismus behandelt wird. Aber wir haben einen anderen Ansatz in pip-tools , der hier gemacht werden könnte.

Das "ursprüngliche" pip-tools -Verhalten besteht darin, dass nur das aktualisiert wird, was in der Sperrdatei benötigt wird (in seinem Kontext die Anforderung.txt), dies ging jedoch in der Art und Weise "verloren", wie der Resolver in pipenv . Lassen Sie mich erklären, warum.

Ich verweise auf meinen Lebenslauf über die Funktionsweise von pip-tools : https://github.com/kennethreitz/pipenv/issues/875#issuecomment -337717817
Erinnern Sie sich an den Teil "Kandidaten auswählen"? Dazu wird das Objekt Repository abgefragt.
In pipenv konfigurieren wir direkt ein PyPIRepository für das Resolver , aber pip-tools macht etwas anderes, es verwendet ein LocalRequirementsRepository Objekt, das Hält die vorhandenen Pins von den zuvor vorhandenen requirements.txt (falls gefunden) und "Fallbacks" von PyPIRepository .

In pip-tools geschieht Folgendes, wenn ein Kandidat ausgewählt wird:

1. Fragen Sie LocalRequirementsRepository nach einem Kandidaten ab, der foobar>=1.0,<2.0 .
2. Überprüfen Sie, ob ein vorhandener Stift diese Anforderungen erfüllt:
   
   
   
   • Wenn ja, geben Sie diesen Pin als Kandidaten zurück.
   
   
   • Wenn nicht, fragen Sie die proxied_repository ( PyPIRepository ) für den Kandidaten ab.
   
   
3. Verwenden Sie den zurückgegebenen Kandidaten

Im Endeffekt bedeutet dies, dass vorhandene Pins eine "Priorität" als Kandidat erhalten, um es zuerst zu versuchen.

Aber in pipenv ist es derzeit einfach:

1. Fragen Sie PyPIRepository (direkt) nach einem Kandidaten ab, der mit foobar>=1.0,<2.0 übereinstimmt.
2. Verwenden Sie den zurückgegebenen Kandidaten.

Ich denke also, dass das gleiche Verhalten für das Sperren in pipenv durch Parsen der Pipfile.lock , um die vorhandenen Pins zu erhalten und ein LocalRequirementsRepository , wie pip-tools tut in seinem Befehl pip-compile .

@vphilippon Hast du ein Gefühl dafür, wie schwierig die Implementierung sein würde?

@ Techalchemy

• Analysieren der Pipfile.lock , um die vorhandenen Pins zu extrahieren: Hab mir das nicht angesehen. Kommt darauf an, wie die Dinge in pipenv strukturiert sind. Wir brauchen einen Satz von InstallRequirements , der die Pins in Pipfile.lock .
• Verwenden von LocalRequirementsRepository : Ziemlich einfach: Ändern Sie unsere aktuellen PyPIRepository gegen LocalRequirementsRepository .

Aber wenn ich mir das anschaue und den Kommentaren von stelle ich einige Dinge fest:

1. Das aktuelle Standardverhalten von pipenv install stimmt nicht mit dem Verhalten von pipenv lock überein. Wenn Sie pipenv install requests alleine machen, werden requests nicht aktualisiert, wenn eine neue Version herauskommt (ähnlich wie bei pip install ). Wenn Sie jedoch pipenv lock ausführen, werden die Pipfile.lock mit der neuesten Version von requests aktualisiert, die dem Pipfile -Spezifizierer und den Abhängigkeitsbeschränkungen entspricht.
   Es gibt zwei Möglichkeiten, dies zu sehen:
   
   
   
   • A) Die Pipfile.lock sollten standardmäßig so stabil wie möglich bleiben und die Pins nicht ändern, es sei denn, dies ist erforderlich, um wie die aktuelle Umgebung zu bleiben, und nur für den Fall, dass wir die Umgebung ändern.
   
   
   • B) Die Pipfile.lock sollten die neuesten Versionen erhalten, die die Umgebungsbeschränkungen / -abhängigkeiten berücksichtigen, um frei von den offenen Bereichen in den Abhängigkeiten Pipfile und lib zu profitieren und kontinuierlich neue kompatible Versionen in zu erwerben Ihre Umgebung. Sie können dann pipenv update ausführen, um von der neuen Sperre zu profitieren.
   
   

IMHO, I would align the default behavior, which would be to go with A) by default. Because right now, everytime a lock is performed (i.e. after each installation), new versions can come in, which make the lockfile *drive the update of the environment*, which seems weird. But, this is arguable of course. While in development, I might want to continuously update my requirements to no get stale, like with B), so that should also be easily doable.

1. Selbst wenn wir LocalRequirementsRepository , um zu vermeiden, dass vorhandene Pins korrekt aktualisiert werden, und am Ende das Standardverhalten ausrichten, müssen wir das Äquivalent von --upgrade und --upgrade-strategy für den Sperrteil adressieren . Derzeit wirkt sich das Definieren einer Umgebungsvariablen (wie PIP_UPGRADE und PIP_UPGRADE_STRATEGY ) auf das Verhalten von pipenv install aus, jedoch nicht auf pipenv lock , da dies keine Auswirkungen hat das Verhalten von pip-tools (das habe ich bestätigt, da ich mir zunächst nicht sicher war).
   Andernfalls gibt es keine Möglichkeit, die Umgebung zu aktualisieren, ohne entweder die Pipfile.lock löschen (fühlt sich klobig an und "alles oder nichts") oder eine neuere Version zu benötigen (ich meine eine explizite pipenv install requests>2.18.4 ,). Dies setzt voraus , dass Sie Pipfile selbst (wodurch die Untergrenze erhöht wird), was falsch ist. Da das "ursprüngliche pip-tools " nicht auf pip , um dies zu behandeln (da es nicht mit dem zusammenhängt, was derzeit installiert ist), bietet es eine Option, um die Abhängigkeiten anzugeben, die im aktualisiert werden sollen Sperren Sie die Datei und entfernen Sie einfach die Pins für diese Pakete (oder alle) aus der Liste der vorhandenen_Pins, sodass Sie effektiv auf die Abfrage von PyPI zurückgreifen können. Ich bin mir nicht sicher, wie wir den Begriff "--upgrade-Strategie" damit in Einklang bringen können.

@ Techalchemy
Während ich sagte, dass es ziemlich einfach war, nur das Standardverhalten auszurichten, wurde mir jetzt klar, dass dies ein großes Problem bei der Aktualisierung der Pakete verursachen würde (wie in: Holen Sie sich einfach die neueste Version, die meinen aktuellen Einschränkungen entspricht). .

Wenn etwas unklar ist, fragen Sie weg, beim Schreiben wurde viel bearbeitet.

(Abhängigkeitsauflösung ist nicht einfach. Gute und praktische Abhängigkeitsauflösung ist sogar am schlechtesten 😄)

@vphilippon genau das habe ich gemeint. Es ist nicht trivial, die von pip installierten Dinge mit den von pip-tools gelösten Dingen synchron zu halten, es sei denn, Sie treiben den Prozess rückwärts und verwenden die aufgelöste Sperrdatei, um die Installation durchzuführen. Ich bin mir ziemlich sicher, dass die Dinge deshalb so gestaltet wurden, wie sie waren.

B) Das Pipfile.lock sollte die neuesten Versionen erhalten, die die Umgebungsbeschränkungen / -abhängigkeiten berücksichtigen, um frei von den offenen Bereichen in den Pipfile- und lib-Abhängigkeiten zu profitieren und kontinuierlich neue kompatible Versionen in Ihrer Umgebung zu erwerben. Sie können dann das pipenv-Update ausführen, um von der neuen Sperre zu profitieren.

Dieser Workflow kann möglicherweise mit der aktuellen Konfiguration funktionieren. Sie können pipenv lock , um eine Sperrdatei zu generieren, aber pipenv update installiert die gesamte Umgebung neu. Ich bin mir ziemlich sicher, dass wir eines unserer verschiedenen Ausgabeformate verwenden können, um das Abhängigkeitsdiagramm aufzulösen (wir haben bereits ein JSON-Format, wie Sie wissen) und nur Dinge neu zu installieren, die nicht an der Sperrdatei ausgerichtet sind. Dies mag sinnvoller sein, aber ich wäre gespannt auf die Eingabe von @nateprewitt oder @erinxocon, bevor treffe

@vphilippon Stimme voll und ganz zu, dass A und B in verschiedenen Situationen wünschenswerte Workflows sind. Einige Ihrer Formulierungen um B haben mich jedoch ein wenig verwirrt und scheinen zu sagen, dass pipenv lock zu einer Sperrdatei führen könnte, die nicht wirklich zur Umgebung passt - ich habe dies besonders gehört, da man " pipenv update ausführen" müsste

Unabhängig davon, ob Sie sich in einem A-Workflow oder einem B-Workflow befinden, scheinen mir einige Dinge konstant zu sein, und ich denke, dies entspricht auch dem, was @techalchemy sagt:

• Das Ergebnis von pipenv lock sollte immer eine Sperrdatei sein, die der Umgebung entspricht.
• Das Ergebnis von pipenv install sollte immer eine Umgebung sein, die mit der Sperrdatei übereinstimmt.

Ich ignoriere Implementierungsdetails, aber das ist das Grundverhalten, das ich von einem Paketmanager mit einer Lockfile-Funktion erwarte.

Wenn Sie pipenv update regelmäßig ausführen, können Sie im B-Modus bleiben, solange alles frisch sein soll. Wenn Sie pipenv install --upgrade requests , können Sie bestimmte Aktualisierungen eines Pakets und seiner Abhängigkeiten durchführen, ohne die Pakete zu beeinträchtigen das muss nicht unnötig aktualisiert werden.

Vermisse ich Anwendungsfälle? Ich kann mir Optimierungen für B vorstellen - z. B. ein Flag oder eine Umgebungsvariable, die es anweist, immer eifrig zu aktualisieren -, aber ich denke, das deckt die Grundlagen ab. Ich weiß auch, dass ich den Boden runderneuere, den Sie bereits zurückgelegt haben. Es ist nur hilfreich für mich, um sicherzustellen, dass ich verstehe, wovon Sie sprechen. :) :)

Einige Ihrer Formulierungen um B haben mich jedoch ein wenig verwirrt und scheinen zu sagen, dass die Pipenv-Sperre zu einer Sperrdatei führen kann, die nicht wirklich der Umgebung entspricht

@brettdh das ist richtig - der pip-tools Resolver, mit dem wir Pipfile.lock generieren, fragt die virtuelle Umgebung nicht nach einer Liste der installierten Pakete. Stattdessen wird eine Liste von Paketen erstellt, die die in der Liste der Pins angegebenen Kriterien aus Pipfile erfüllen. Da der Resolver selbst mit dem System oder der Installation von python / pipenv / pip-tools ausgeführt wird, versuchen wir, ihn davon zu überzeugen, Pakete mit derselben Python-Version aufzulösen, die in virtualenv verwendet wird. Die Annahme wäre, dass pip install die Dinge ähnlich lösen würde, aber das ist nicht immer der Fall, obwohl ich mir darüber nicht 100% sicher bin. Aber ja, pipenv lock wird nicht basierend auf der virtuellen Umgebung generiert, sondern basierend auf Pipfile . Es handelt sich um eine Sperrdatei für die Abhängigkeitsauflösung, nicht um einen Umgebungsstatus-Pin.

Als mögliche Lösung hierfür: Etwas, das Pip selbst derzeit unterstützt, pip-compile jedoch nicht, ist der Begriff einer Einschränkungsdatei.

Eine Einschränkungsdatei unterscheidet sich von einer Anforderungsdatei dadurch, dass sie lautet: " Wenn diese Komponente installiert ist, muss sie diese Versionsbeschränkung erfüllen". Wenn jedoch ein bestimmtes Paket in der Einschränkungsdatei nirgendwo im Abhängigkeitsbaum angezeigt wird, wird es nicht zu den zu installierenden Paketen hinzugefügt.

Dies ist die Funktion, die derzeit in pipenv fehlt, da die gewünschten Eingaben für die Generation Pipfile.lock sind:

1. Der aktualisierte Inhalt von Pipfile als neue Anforderungseingabedatei
2. Der vollständige Satz vorhandener Abhängigkeiten von Pipfile.lock als Einschränkungsdatei, ausgenommen die im aktuellen Befehl speziell genannten Pakete

Die Unterstützung von Constraints-Dateien auf der Pip-Tools-Resolver-Ebene würde dann ausreichen, damit pipenv einen Modus unterstützt, in dem versuchte implizite Upgrades von Abhängigkeiten als Einschränkungsverletzung fehlschlagen und der Benutzer entscheiden kann, ob er hinzufügen möchte oder nicht das Paket zu dem Satz, der aktualisiert wird.

Derzeit nicht unterstützt, danke für das Feedback

@ Kennethethreitz

Meinst du:

1. Dieses Verhalten sollte geändert werden, hat aber derzeit keine Priorität.
2. Dieses Verhalten sollte optional hinzugefügt werden, hat aber derzeit keine Priorität
3. Dieses Verhalten sollte nicht hinzugefügt werden?

Dies ist eine ausreichende Unannehmlichkeit angesichts der Inkonsistenz mit der Arbeitsweise anderer ähnlicher Manager von Schließpaketen. Es wäre gut, dies als Werbung für PRs offen zu halten.

Wenn es stattdessen (3) ist und dies nicht hinzugefügt wird, müssen einige von uns in dieser Angelegenheit unsere Pläne für die Auswahl der Python-Paketverwaltungstools anpassen.

Ich meine, dass dies derzeit nicht unterstützt wird, und ich freue mich über das Feedback.

Ich verstehe, dass es nicht unterstützt wird. Wollen Sie damit auch sagen, dass Sie keine PRs akzeptieren würden, die dieses Verhalten ändern oder dies als Option hinzufügen?

Ich habe keine Ahnung.

@ k4nar immer noch daran interessiert, eine PR dafür zu machen? Insbesondere etwas wie pipenv install --only <dep-to-update das verhindert, dass nicht verwandte Deps aktualisiert werden. Da @kennethreitz nicht daran interessiert zu @taion und ich pipenv weiterhin verwenden können).

Ich bin interessiert, aber ich bin mir nicht sicher, wie ich dies am besten umsetzen kann. Es sind viele Komponenten in Aktion (Pip, Pip-Tools, Pipfile, Pipenv…) und wahrscheinlich viele mögliche Lösungen.

Per https://github.com/kennethreitz/pipenv/issues/966#issuecomment -339707418 sollte es relativ einfach sein. Diese Logik der Auflösung basiert größtenteils nur auf Pip-Tools. Ich hatte vor, eine PR einzureichen, aber ich kann es nicht rechtfertigen, die Arbeit auszugeben, wenn wir nicht bereit sind, darüber zu sprechen, wie die API aussehen soll, bevor wir Zeit mit dem Schreiben von Code verbringen.

Ich suche derzeit nach einem alternativen Ansatz - da Pipfile ein Standard ist, müssen Interaktionen mit ihm nicht über pipenv erfolgen, und ich möchte einige der anderen merkwürdigen Semantiken hier umgehen, z. B. das Löschen vorhandener virtueller Envs per https : //github.com/kennethreitz/pipenv/issues/997.

Es tut mir leid, ein geschlossenes Problem zu kommentieren, aber ich möchte darauf hinweisen, dass nach meinem Verständnis die Verwendung von pipenv in meinen Projekten derzeit einen Workflow wie den folgenden erfordert:

pipenv install foo
vim Pipfile.lock  # Manually remove all the unwanted updates
git add && git commit && git push

Ich finde es wirklich ärgerlich, dies meinen Teammitgliedern mitteilen zu müssen. Die Alternative scheint darin zu bestehen, alles auf exakte Versionen in Pipfile fixieren, aber das macht einen Großteil des Zwecks der Verwendung von pipenv zunichte.

IIUC, dieses Verhalten entspricht apt und führt ein implizites apt dist-upgrade wenn Sie apt install foo ausführen.

Dies wird durch die Tatsache verschlimmert, dass pipenv install Inhalte in Pipfile.lock aktualisiert, die Updates jedoch nicht in der lokalen virtuellen Umgebung installiert. Wenn der Entwickler den Unterschied von Pipfile.lock nicht sorgfältig untersucht, verwendet er immer noch die älteren Versionen lokal, aber sobald er den Code gemeinsam nutzt, sehen alle anderen Umgebungen die überraschenden Updates. Menschen neigen dazu, den Unterschied von Pipfile.lock zu ignorieren, da er als automatisch generierte Datei betrachtet wird.

Ich bin der festen Überzeugung, dass "alles auf die neueste Version aktualisieren, die von Pipfile erlaubt ist" eine explizit angeforderte Operation sein sollte, die von "install foo" getrennt ist.

sollte im Master behoben werden

Das Verhalten ist immer noch vorhanden, ich habe es in pipenv 11.8.3 , @kennethreitz getestet.

@ marius92mc Der Kommentar "Fixed in Master" bezieht sich auf die Optionen --selective-upgrade und --keep-outdated , die in den letzten Versionen hinzugefügt wurden: https://docs.pipenv.org/#cmdoption -pipenv-install-keep -veraltet

Dies ermöglicht es Leuten, die mehr Kontrolle darüber benötigen oder wollen, wann Upgrades stattfinden, sich für dieses Verhalten zu entscheiden, während das Standardverhalten weiterhin OWASP A9 respektiert und bei jeder Gelegenheit auf eifrige Upgrades drängt.

@ncoghlan Ich denke, eine Sache, die benötigt wird (einfach zu fragen, nicht so einfach zu tun), ist eine FAQ zu _wie_ sich diese Optionen verhalten (zumindest ist es für mich immer noch verwirrend).

Beispiel: Wenn Sie --selective-upgrade und --keep-outdated werden veraltete Bibliotheken in Pipfile.lock weiterhin aktualisiert, wenn sie nicht direkt mit dem zu aktualisierenden "ausgewählten" Paket zusammenhängen .

Es hört sich dann so an, als ob es Implementierungsfehler geben könnte.

Sie sollen die pipfile.lock bis auf die neue Änderung unverändert lassen.

Lassen Sie mich wissen, ob es hilfreich ist, ein Test-Pipfile + .lock bereitzustellen.

Ich denke, Sie haben genug Informationen zur Verfügung gestellt, damit wir nachforschen können. Ich werde das jetzt versuchen.

Eigentlich wäre Ihre Pipfile / Sperre großartig, wenn sie veraltete Ergebnisse enthält.

@ncoghlan , danke für die Bereitstellung der Details.
Ich habe es mit Ihren genannten Optionen erneut versucht und das Ergebnis scheint dasselbe zu sein. Es aktualisiert weiterhin die anderen Pakete und ändert sie in der Datei Pipfile.lock .

@kennethreitz https://github.com/simonpercivall/pipenv-selective-upgrade-test

Gibt es Updates zu diesem Problem, @kennethreitz?

Entschuldigung für die langsamen Antworten. Wir haben die Grundursache für die Regression hier noch nicht gefunden (ich weiß, dass ich persönlich an diesem Wochenende eine Rechenzentrumsmigration durchgeführt habe, also war ich etwas langsam), aber wir werden dies in den nächsten Tagen klären.

Beiträge sind wie immer willkommen!

Ich denke, es gibt einen fehlenden Anwendungsfall, der dieselbe Änderung verwenden kann: Wenn ich eine Anwendung entwickle, muss ich häufig die Version einer einzelnen Abhängigkeit aktualisieren. Die Schritte, denen ich folgen möchte, sind:

1. Aktualisieren Sie die Versionsbeschränkung für die Abhängigkeit in setup.py
2. Führen Sie entweder pipenv lock --selective-upgrade ; pipenv sync oder pipenv install --selective-upgrade "-e ."

@wichert Wenn Pipfile so bearbeitet wurde, dass die erforderliche Mindestversion über die aktuelle Sperrdatei hinausgeht, sollte --keep-outdated bereits das abdecken, was Sie benötigen. --selective-upgrade ist für den Fall vorgesehen, dass sich Pipfile nicht geändert hat, Sie aber trotzdem auf eine neue angeheftete Version aktualisieren möchten.

@ncoghlan Pipfile hat sich in diesem Szenario nicht geändert, sondern nur setup.py indem die Mindestversionsanforderungen für eine Abhängigkeit geändert wurden, normalerweise auf etwas Neueres und derzeit in Pipfile.lock .

@wichert pipenv erfasst Änderungen an Ihrem setup.py automatisch, da es sich nicht um Setuptools handelt. Sie müssen pipenv lock ausführen, wenn dies geschehen soll.

Wie ist der aktuelle Status davon? Am 25. März sagte jemand, dass sie dachten, Implementierungsprobleme würden "in den nächsten Tagen" behoben, und andere Fehlerberichte wurden geschlossen, weil sie hier verfolgt wurden. Ab 2018.7.1 wird jedoch immer noch der von Simon Percivall gemeldete Fehler angezeigt (indirekte Abhängigkeiten werden immer aktualisiert), und dieser Fehler wurde seit dem ursprünglichen Bericht nicht mehr erörtert. Wird das Problem noch verfolgt?

(Ich lebe derzeit in einer zweitrangigen Stadt im Senegal, daher ist mein Internet schrecklich und es wäre ein Spielveränderer, wenn ich meine Datenbeschränkung bei der Aktualisierung indirekter Abhängigkeiten nicht sprengen würde, wenn möglich: P)

PS: Danke, dass du Pipenv gemacht hast, es ist großartig <3

Ja sicherlich. Wir schreiben den Resolver neu, um dies jetzt zu unterstützen. Ob es in dieser oder der nächsten Version landet, bleibt abzuwarten

Ich bin nicht so sicher mit meiner Codierungsfähigkeit, um abzuschätzen, wann der Resolver landen würde: p Im Ernst, dies ist ein vollständig freiwilliges Projekt, und wir haben keinen Terminmechanismus wie Sie es in kommerziellen Umgebungen tun würden (wir haben nicht einmal einen ein Chef oder ein Projektmanager oder was auch immer Sie in Ihrem Unternehmen haben, der entscheidet, wann etwas getan werden muss). Wenn Sie möchten, dass etwas in einem von Ihnen gewünschten Zeitraum erledigt wird, müssen Sie es selbst tun oder zumindest andere wirklich motivieren, dies zu tun.

@uranusjr FWIW, ich habe in @benkuhns Kommentar oben keine Anforderungen an die Zweckmäßigkeit

Ich verstehe, dass pipenv ein freiwilliges Projekt ist und dass Nicht-Mitwirkende nicht verlangen können, dass etwas bis zu einem Datum erledigt wird, ohne sich anzumelden, um dies zu erreichen. Ich frage mich, ob es Raum für mehr Transparenz im Entwicklungsprozess des Projekts gibt oder ob ich einfach nicht an den richtigen Stellen suche. Normalerweise lautet die Antwort entweder "Wenn das Problem nicht aktualisiert wurde, gab es keine Bewegung" oder "Sehen Sie sich diese WIP-Pull-Anforderung an", aber dieses Problem scheint insbesondere einen viel größeren Aufwand ausgelöst zu haben, sodass die Punkte schwierig sein können für diejenigen, die nicht direkt beteiligt sind, zu verbinden.

Wie immer vielen Dank an Sie und alle, die ihre wertvolle Zeit für die Verbesserung von pipenv geben. 👏

Sicherlich hat dieser keine Aktivität oder PR in Arbeit, weil es viel komplizierter ist. Wir sprechen intern hauptsächlich darüber, wie wir dies in Bezug auf das größere Projekt überhaupt strukturieren wollen, und arbeiten iterativ daran, einen Ansatz zu etablieren, der möglicherweise sogar richtig funktioniert. Sobald wir das klären können, können wir eine Auflösungslogik erstellen.

In der Zwischenzeit ist der Resolver-Stack in pipenv sehr kompliziert und ich würde es nicht gerne tun, wenn ich die Leute auffordere, zu viel Aufwand zu betreiben, um ihn für diesen Zweck zu entwirren. Selbst der einfachste Anwendungsfall hier wird einen signifikanten Refaktor erfordern. Wir würden uns freuen, einen vorgeschlagenen Refactor zu prüfen / zu diskutieren, wenn jemand daran interessiert ist, dies in Angriff zu nehmen, aber die beiden Dinge sind eng miteinander verbunden.

Wenn jemand Erfahrung in der Auflösung von Abhängigkeiten und in der Lösung von Satelliten hat, wären wir sicherlich an Eingaben interessiert, aber es gibt noch keine konkrete Idee. Wir haben mehrere Iterationen durchlaufen, die wir nie als mehr als Proof of Concept durchführen wollten. Nicht jeder Code wird zu einer PR, und nicht alle Entscheidungen zur Codeorganisation werden auf dem Issue Tracker getroffen. Manchmal unterhalten wir uns synchron und schlagen Ideen in Echtzeit vor und verschrotten sie.

Etwas, das ich als alternativen Workflow vorschlagen wollte, um dies zu beheben, macht es einfach, bei der Installation eine bestimmte Version in der Pipeline-Datei anzuheften.

Ich denke, es ist etwas überraschend, aber nicht völlig unvernünftig, dass pipenv foo = "*" so interpretiert, dass es bedeutet: "Ich muss nur sicherstellen, dass eine Version von foo installiert ist, dem Benutzer ist es egal, welche". Zu diesem Zweck scheint es so, als ob es so etwas wie pipenv install --pin foo was zu foo = "==1.2.3" anstelle von foo = "*" im Pipfile führt (wobei 1.2.3 die aktuellste Version von foo ist) Hilfe.

Das Problem dabei ist jedoch, dass sich das Verhalten vieler Pakete aufgrund ihrer Abhängigkeiten stark ändern kann (z. B. kann dieselbe Pylint-Version je nach verwendeter Astroid-Version völlig unterschiedliche Aufgaben ausführen) und Pakete nicht Pin ihre eigenen Deps genau. Ich glaube also nicht, dass dies jemanden wirklich weit bringt. : /

(Ich habe gerade festgestellt, dass ich das falsche Problem kommentiert habe. Entschuldigen Sie das Durcheinander, bitte ignorieren Sie mich) 😞

Ein tatsächlicher Anwendungsfall, mit dem ich seit einigen Stunden zu kämpfen habe: Ich möchte die Testabdeckung in einem Django 2.0-Projekt messen. Sogar pipenv install --keep-outdated --selective-upgrade --dev coverage besteht darauf, das Nicht-Entwickler-Django-Paket auf Version 2.1 zu aktualisieren, die ich aufgrund von Schäden an anderen Stellen noch nicht verwenden kann. Es muss wirklich eine Möglichkeit geben, den Satz installierter Pakete zu ändern, ohne völlig unabhängige Pakete auf möglicherweise fehlerhafte Versionen zu aktualisieren. Die Möglichkeit eines Bruchs in der neuesten Version besteht immer.

Ich werde versuchen, die Problemumgehung von @rfleschenberg zu umgehen , aber ich weiß nicht, ob eine vermutlich falsche _meta hash -Eigenschaft irgendetwas kaputt macht.

@ l0b0 Wenn Ihre Anwendung eine bestimmte Version von Django wirklich nicht verarbeiten kann, ist es meiner Meinung nach sinnvoll, diese Einschränkung in Ihrem Pipfile anzugeben?

@AlecBenzer Das klingt für mich nach etwas für setup.py.

@wichert Das mag auch Sinn machen (mir ist eigentlich nicht ganz klar, unter welchen Umständen Sie sowohl eine setup.py als auch eine Pipfile haben möchten), aber wenn Sie eine Zeile in Ihrer Pipfile haben, die besagt:

Django = "*"

Sie sagen pipenv, dass es _jede_ Version von Django installieren soll. Wenn Sie wirklich möchten, dass 2.0 oder niedriger installiert wird, sagen Sie stattdessen Folgendes:

Django = "<=2.0.0"

Während in diesem speziellen Fall pipenv Django ohne wirklichen Grund aktualisiert, kann es sein, dass Sie irgendwann versuchen, ein Paket zu installieren, für das Django> 2.0.0 erforderlich ist. Pipenv installiert es dann gerne, wenn Sie es nicht gesagt haben es, dass Sie <= 2.0.0 benötigen.

Wenn Sie wirklich möchten, dass 2.0 oder niedriger installiert wird, teilen Sie dies stattdessen mit

@AlecBenzer beim Nachdenken fällt mir jetzt ein, dass npm / yarn dies standardmäßig tut, wenn Sie ein Paket installieren; Sie finden die neueste Version von major.minor und geben in package.json ^major.minor.0 an, wodurch unerwartete Aktualisierungen der Hauptversion verhindert werden, selbst wenn ausdrücklich ein Upgrade auf die neueste Version angefordert wird. Ich frage mich, ob Pipenv dasselbe tun sollte - aber das wäre ein separates Problem.

Natürlich verhindert ihre Sperrdatei auch versehentliche Upgrades von Neben- und Patch-Versionen, was hier angefordert wird.

Ich denke, es wurde oben und anderswo diskutiert, aber es gibt eine Spannung / einen Kompromiss im Designraum zwischen npm / Garn und Pipenv. Jeder Paketmanager hat angeblich diese Ziele mit einer relativen Priorität:

• Erleichtern Sie die Installation und Aktualisierung von Paketen
• Machen Sie es sich schwer, Ihre App versehentlich mit einem fehlerhaften Abhängigkeits-Upgrade zu beschädigen

Das Problem beim Fixieren einer genauen Version in der Pipfile besteht darin, dass es dann schwieriger ist, Pakete zu aktualisieren. Aus diesem Grund gibt es Pip-Tools (obwohl es sich um die

Das --keep-outdated -Flag scheint nicht wie beabsichtigt zu funktionieren, wie beim erneuten Öffnen des Problems angegeben wurde. Ob dieses Verhalten die Standardeinstellung sein sollte oder nicht und wie es mit anderen Paketmanagern übereinstimmt, ist hier nicht wirklich das zentrale Thema. Lassen Sie uns das Problem zuerst beheben.

@brettdh

Nach dem Nachdenken fällt mir jetzt ein, dass npm / yarn dies standardmäßig tut, wenn Sie ein Paket installieren. Sie finden die neueste Version von major.minor und geben in package.json ^ major.minor.0 an, wodurch unerwartete Aktualisierungen der Hauptversion verhindert werden, selbst wenn ausdrücklich ein Upgrade auf die neueste Version angefordert wird. Ich frage mich, ob Pipenv dasselbe tun sollte - aber das wäre ein separates Problem.

Ja, das entspricht dem, was ich in https://github.com/pypa/pipenv/issues/966#issuecomment -408420493 vorschlagen wollte

Wirklich aufgeregt zu hören, dass daran gearbeitet wird!

Hat in der Zwischenzeit jemand eine vorgeschlagene Problemumgehung, die weniger mühsam und fehleranfällig ist als das Ausführen von pipenv lock und das manuelle Zurücksetzen der resultierenden Änderungen an der Sperrdatei, die ich nicht anwenden möchte?

@benkuhn Nicht, dass ich es wüsste - ich mache die ganze Zeit das gleiche Lock & Revert Dance.

Ah ok, Sie können zumindest manchmal das Zurücksetzen von Hand vermeiden:

1. pipenv lock
2. git commit -m "FIXME: revert"
3. pipenv install packagename
4. git commit -m 'Add dependency on packagename'
5. git rebase -i
6. Löschen Sie das Commit FIXME: revert

Leider ist es immer noch möglich, ein inkonsistentes Pipfile.lock zu erstellen, wenn Ihr Pipfile.lock anfängt, eine Version eines Pakets zu enthalten, das zu alt ist, um die Anforderungen von packagename zu erfüllen, aber vielleicht wird sich pipenv beschweren darüber, wenn es passiert?

--keep-outdated scheint systematisch nur die expliziten Abhängigkeiten veraltet zu halten, die in Pipfile angegeben (nicht fixiert) sind, während alle impliziten Abhängigkeiten aktualisiert werden.

Stimmt es, dass es nicht möglich ist, einzelne Abhängigkeiten mit pipenv==2018.7.1 zu aktualisieren / installieren, ohne andere Abhängigkeiten zu aktualisieren? Ich habe verschiedene Kombinationen von --selective-upgrade und --keep-outdated ohne Erfolg ausprobiert.

Das manuelle Bearbeiten von Pipfile.lock macht keinen Spaß ...

Genau wie bei @ max-arnold ist es mein erster Tag, an dem ich das Tool in einem vorhandenen Projekt verwende, und ich muss sagen, dass ich wirklich enttäuscht bin . Bevor ich damit begann, habe ich die Dokumentenseite und die Videodemo überprüft. Es sah beeindruckend aus Für mich und jetzt das: In einem echten Projekt ist die Arbeit mit pip oder pipenv fast gleich, ich verstehe den Punkt nicht, wie viele andere im Thread gesagt haben, wenn ich habe eine Sperrdatei, warum Sie meine anderen Abhängigkeiten aktualisieren, wenn sie nicht aktualisiert werden müssen.

### Wenn das Update obligatorisch ist, ist es natürlich in Ordnung, alle erforderlichen Abhängigkeiten zu aktualisieren, aber nur diese, nicht alle veralteten.

Auch die Optionen --selective-upgrade und --keep-outdated sind nicht klar, wofür sie nützlich sind. Es gibt ein weiteres Problem, das dies hier hervorhebt # 1554, und niemand kann darauf reagieren, was diese Optionen bewirken, unglaublich.

Meine größte Enttäuschung ist jedoch, warum dieses Paket von der offiziellen Python-Dokumentation selbst empfohlen wurde. Diese Empfehlungen sollten sorgfältiger durchgeführt werden. Ich weiß, dass dies ein großartiges Projekt in der Funktion sein kann, viel Potenzial hat, aber einfache Dinge wie diese (wir) sprechen nicht über einen Fehler oder eine kleinere Funktion), machen dieses Projekt nicht für Produktionsumgebungen geeignet, aber plötzlich, weil es von den Python-Dokumenten empfohlen wurde, versuchen alle, es zu verwenden, anstatt nach anderen Tools zu suchen, die möglicherweise besser funktionieren. oder bleiben Sie einfach bei pip , das auch diese Probleme nicht löst, aber zumindest sehr minimalistisch ist und meistens in jeder Umgebung enthalten ist (ohne zusätzliche Abhängigkeiten).

@mrsarm Vielen Dank für Ihre Meinung. Entschuldigung, die Dinge funktionieren bei Ihnen nicht. Ich verstehe jedoch nicht, woher die Enttäuschung kommt. Niemand zwingt Pipenv irgendjemandem auf; Wenn es bei Ihnen nicht funktioniert, verwenden Sie es nicht. So funktionieren Empfehlungen.

Ihr Geschwätz hat auch nichts Besonderes mit diesem Thema zu tun. Ich verstehe, dass es ein wenig Selbstbeherrschung erfordert, keinen Müll auf Menschen zu werfen, wenn die Dinge nicht in Ihre Richtung gehen, aber bitte zeigen Sie etwas Respekt und unterlassen Sie dies.

@uranusjr es ist kein Müll, es ist eine Meinung, und manchmal ist es keine Option, wie in meinem Fall, wo jemand pipenv gewählt hat, um ein Projekt zu erstellen, in dem ich jetzt angefangen habe zu arbeiten, und ich muss mich damit befassen.

Aber gerade jetzt wird es schlimmer, und was ich sagen werde, ist keine Meinung, sondern eine Tatsache.

Nachdem ich versucht hatte, eine Abhängigkeit hinzuzufügen, die ich gerade verworfen hatte, um dieses Problem nicht zu lösen (da es sich um eine Entwicklungsabhängigkeit handelt, habe ich eine zweite Umgebung mit pip und dem alten requirements-dev.txt -Ansatz erstellt, nur mit dieses Tool) musste ich eine weitere Abhängigkeit hinzufügen.

Die neue Abhängigkeit ist PyYAML, sagen wir die neueste Version. Wenn Sie es in einer neuen Umgebung mit pip installieren, werden Sie feststellen, dass die Bibliothek keine Abhängigkeit hinzufügt, sodass nur PyYAML installiert ist. In diesen Fällen ist dies mit Pip so einfach. Beim Hinzufügen der Abhängigkeit mit Pipenv (da ein Projekt, das ich nicht erstellt habe, mit Pipenv verwaltet wird) trat das gleiche Problem auf, obwohl PyYAML keine Abhängigkeit aufweist und zuvor nicht im Projekt installiert war (eine ältere Version), pipenv aktualisiert alle meine Abhängigkeiten in der Sperrdatei und in der virtuellen Umgebung, aber ich möchte die anderen Abhängigkeiten nicht aktualisieren, sondern nur eines, um ein einzelnes neues Modul ohne Abhängigkeit hinzuzufügen.

Die Schlussfolgerung (und wieder eine Meinung, nicht eine Tatsache wie pipenv, die alle meine Abhängigkeiten gebrochen hat) ist, dass Pipenv, anstatt mir zu helfen, mit dem Abhängigkeitsmanagement umzugehen, es in die Hölle verwandelt.

Ich verfolge diesen Thread seit Monaten und ich denke, dass jedes echte Projekt letztendlich auf dieses Problem stoßen wird, da das Verhalten unerwartet, kontraintuitiv und ja: gefährlich ist.

Vor ungefähr einem Monat habe ich eine umfassendere Alternative zu pipenv , poetry ausprobiert. es löste die Probleme, die ich lösen musste:
1) Verwalten eines Satzes von Abhängigkeiten (setup.py, setup.cfg, pip und pipfile -> pyproject.toml)
2) zukunftsorientiert, abwärtskompatibel (wieder pyproject.toml )
3) ziemlich unvoreingenommen ( nein, ich bitte wirklich nicht darum, redis zu installieren )
4) und die Lösung für das klassische Pipenv-Problem: "Außerdem müssen Sie [pipenv] ausdrücklich anweisen, die gesperrten Pakete nicht zu aktualisieren, wenn Sie neue installieren. Dies sollte die Standardeinstellung sein." [[1] (https://github.com/sdispater/poetry#what-about-pipenv)] [[2] (https://github.com/pypa/pipenv/issues/966#issuecomment-339117289)]

Ich habe gewogen, diese Gedanken über das Thema pipenv teilen , aber wie

• Als Haftungsausschluss bin ich kein Mitglied des Poetry-Teams oder mit ihnen verbunden.

ps Ich denke, die Sorge, dass Pipenv die "offizielle" Lösung ist, beruht auf erstklassigen Integrationen - etwas, das Sie, @uranusjr , möglicherweise als einfache Empfehlung

Niemand zwingt Sie, an unserem Issue-Tracker teilzunehmen. Wenn Sie keinen produktiven Kommentar haben, finden Sie ein Forum, in dem Sie keine Probleme lösen können.

Für Benutzer, die den alternativen Resolver @uranusjr ausprobieren möchten und den ich bereits seit mehreren Wochen implementiere, probieren Sie bitte https://github.com/sarugaku/passa aus , um kompatible Sperrdateien zu generieren. Poesie macht viele verschiedene Dinge, aber sie hat auch Einschränkungen und Probleme selbst, und wir haben eine Designphilosophie, die sich über den Umfang nicht einig ist.

Dies ist ein Projekt, das wir in unserer Freizeit verwalten. Wenn Sie etwas repariert sehen möchten oder einen besseren Ansatz haben, nehmen wir gerne Beiträge entgegen. Wenn Sie hier sind, um uns einfach zu sagen, dass wir Ihren Tag und Ihr Projekt ruiniert haben, werde ich Sie nur einmal bitten, sich selbst zu sehen.

Wir haben dieses Problem nicht vergessen oder ignoriert. Wir haben eine vollständige Implementierung eines Fixes in dem oben verlinkten Resolver. Haben Sie Geduld, seien Sie höflich oder finden Sie einen anderen Ort zum Reden. Wenn Sie geduldig auf eine Lösung gewartet haben, probieren Sie bitte den oben genannten Resolver aus. Wir sind gespannt, ob er Ihren Anforderungen entspricht. Es implementiert eine ordnungsgemäße Rückverfolgung und Auflösung und sollte diese Upgrade-Strategie nicht handhaben

Kurzfristig denke ich, dass wir ein Pflaster dafür in pipenv bekommen können, wenn wir nicht zuerst abschneiden.

@dfee Ich bin mir nicht sicher, ob das Verwischen von Linien zwischen Anwendungen und Bibliotheken die richtige Antwort auf das Abhängigkeitsmanagement ist, daher sehe ich den Ansatz von Poesie nicht als Vorteil. Ich war nicht an Ihrem Problem mit der Empfehlungs-Engine beteiligt, aber das haben wir vor einiger Zeit herausgenommen ...

@ Techalchemy

Ich bin mir nicht sicher, ob das Verwischen von Linien zwischen Anwendungen und Bibliotheken die richtige Antwort auf das Abhängigkeitsmanagement ist, daher sehe ich den Ansatz der Poesie nicht als Vorteil.

Warum allerdings? Ich habe diese Idee nie verstanden, dass Sie die Abhängigkeiten einer Bibliothek und einer Anwendung unterschiedlich verwalten sollten. Der einzige Unterschied zwischen beiden ist die Sperrdatei, die für eine Anwendung benötigt wird, um eine reproduzierbare Umgebung zu gewährleisten. Davon abgesehen ist es dasselbe. Dies ist der Standard in den meisten anderen Sprachen, und Python scheint hier aus irgendeinem Grund die Ausnahme zu sein, und dies ist vom Standpunkt der Benutzererfahrung aus schlecht, da dies die Dinge komplexer macht, als sie sein sollten.

Es hat auch Einschränkungen und Probleme selbst

Welche? Ich bin sehr gespannt auf die Probleme oder Einschränkungen, auf die Sie bei der Verwendung von Poetry gestoßen sind.

Ich entschuldige mich dafür, dass ich so unhöflich bin. Wenn ich jetzt meine Kommentare lese, stelle ich fest, dass trotz der Informationen, die ich zur Verfügung gestellt habe und einige meiner Optionen noch gültig sind (IMHO), sie nicht so angeeignet wurden, wie ich geschrieben habe, was ich sagen wollte.

Ich verstehe, dass der Issue-Tracker am besten dazu geeignet ist, Fehler und Verbesserungen zu diskutieren und zu diskutieren, ob dies ein Fehler oder ein Fehler ist, der im Thread nicht klar ist, aber ich entschuldige mich erneut.

Ich denke, hier gibt es zwei starke Themen:

• Sollte pipenv alle Ihre veralteten Abhängigkeiten aktualisieren, bei denen Sie nur versuchen, eine neue Abhängigkeit zu installieren: Diejenigen, die nicht aktualisiert werden müssen, weil das neue Paket / die neue Version, die wir installieren möchten, mit den vorhandenen Abhängigkeiten funktionieren kann, und sogar mit denen, die es nicht gibt Sind die Abhängigkeiten des neuen Pakets, das wir installieren möchten, nicht vorhanden? Vielleicht liegt dies außerhalb des Geltungsbereichs dieses Tickets, aber es ist ein wirklich wichtiges Thema, das diskutiert werden muss.
• Erlaubt uns einer dieser Parameter --keep-outdated --selective-upgrade , dieses Verhalten zu vermeiden? Es ist nicht klar, was diese Optionen bewirken, es fehlt an Dokumentation darüber, und selbst in der entsprechenden Ausgabe (Nr. 1554) antwortet niemand darauf.

Falls es sich um einen Fehler in einem dieser Parameter handelt --keep-outdated --selective-upgrade , denke ich immer noch, dass es eine wirklich schlechte Idee ist, nicht festzulegen, welcher Parameter die unnötige Aktualisierung der Abhängigkeiten als Standard löst.

Stellen Sie sich zum Vergleich mit einem ähnlichen Szenario vor, dass Sie apt-get install vim ausführen, um nur das Tool vim in Ihrem System zu installieren (und ggf. die Abhängigkeiten oder Aktualisierungen der erforderlichen vim), aber stellen Sie sich dies auch in dieser Situation vor apt aktualisiert alle anderen Abhängigkeiten Ihres Systems: Python, das QT-System, den Linux-Kernel ... und so weiter. Es ist nicht so, dass apt uns nicht erlauben sollte, andere Abhängigkeiten zu aktualisieren, aber es gibt einen klaren Befehl, um dies zu tun: apt-get upgrade , während apt-get install PACKAGE nur PACKAGE und seine Abhängigkeiten installieren / aktualisieren.

@sdispater Die Unterscheidung ist der Kern jeder Meinungsverschiedenheit, die wir jemals hatten, und sie ist unglaublich subtil, aber ich würde Sie auf https://caremad.io/posts/2013/07/setup-vs-requirement/ oder eine gute verweisen Artikel für den Elixier-Anwendungsfall: http://blog.plataformatec.com.br/2016/07/understanding-deps-and-applications-in-your-mixfile/

pyproject.toml wird für Bibliotheksdefinitionsmetadaten nicht wirklich unterstützt - und überhaupt nicht von einer Version von pip, die die Peps 517 und 518 (für die beide noch Implementierungsdetails ausgearbeitet haben) nicht als maßgeblich implementiert Bibliotheksdeklarationsdatei. setup.cfg existiert zu diesem Zweck (der eigentliche Nachfolger von setup.py ) und IMHO sollten beide wirklich unterstützt werden. Eine Bibliothek wird veröffentlicht und ist für den Konsum mit abstrakten Abhängigkeiten vorgesehen, damit sie mit anderen in der Sandbox gut spielen können. Anwendungen sind normalerweise große, komplexe Tiere mit manchmal Hunderten von direkten Abhängigkeiten. Einer unserer Hauptunterschiede besteht darin, dass wir dies auch berücksichtigen, wenn wir unsere Werkzeuge entwerfen und bauen

@mrsarm Bei Ihrer ersten Frage war das Aktualisierungsverhalten beabsichtigt (und wurde zu diesem Zeitpunkt ausführlich besprochen, / cc @ncoghlan und im Zusammenhang mit OWASP-Sicherheitsbedenken). Zum zweiten Punkt ist das Verhalten derzeit nicht richtig implementiert, weshalb das Problem immer noch offen ist, was dazu führte, dass wir den oben erwähnten Backing Resolver hinter pipenv neu geschrieben haben. Dieses Verhalten wurde einfach nicht unterstützt. --selective-upgrade soll selektiv nur Dinge aktualisieren, die Abhängigkeiten des neuen Pakets sind, während --keep-outdated alles zurückhalten würde, was die von einem neuen Paket geforderten Abhängigkeiten erfüllt. Etwas anders, aber ich bin mir ziemlich sicher, dass beides momentan nicht richtig funktioniert.

pyproject.toml wird für Bibliotheksdefinitionsmetadaten nicht wirklich unterstützt - und überhaupt nicht von einer Version von pip, die die Peps 517 und 518 (für die beide noch Implementierungsdetails ausgearbeitet haben) nicht als autorisierende Bibliotheksdeklarationsdatei implementiert . Zu diesem Zweck gibt es setup.cfg (der eigentliche Nachfolger von setup.py) und IMHO sollten beide wirklich unterstützt werden.

Nun, das ist sicherlich kein Thema, aber es ist eine wichtige Diskussion, deshalb kann ich mir nicht helfen.

Es gibt derzeit keinen Standard um setup.cfg außer den Konventionen, die von Distutils und Setuptools festgelegt wurden. pyproject.toml ist absolut für Bibliotheksmetadaten als Nachfolger von setup.py oder die Community hätte stattdessen Build-Anforderungen in setup.cfg .

pyproject.toml beschreibt, wie ein Projekt erstellt wird (PEP 518), und ein Teil der Erstellung beschreibt Metadaten. Ich sage NICHT, dass pyproject.toml einen Standardspeicherort für diese Metadaten benötigt, aber PEP 518 verwendet diese Datei, um ein Build-Tool zu installieren, und von dort ist es sehr vernünftig zu erwarten, dass das Build-Tool eine deklarative Konfiguration von einem anderen Ort verwendet in der Datei, um zu bestimmen, wie das Projekt erstellt werden soll.

Wie auch immer, zurück zu Pipenv vs Poetry - es scheint eine Idee zu geben, dass Anwendungen keine bestimmten Funktionen benötigen, die Bibliotheken erhalten, wie z. B. Einstiegspunkte, und dies ist einfach falsch. Es sollte für eine Anwendung unkompliziert sein, ein Python-Paket zu sein.

Der einzig wahre Unterschied zwischen einer Anwendung und einer Bibliothek in meiner Erfahrung mit Python und anderen Ökosystemen besteht darin, ob Sie eine Sperrdatei verwenden oder nicht. Natürlich gibt es einen dritten Fall, in dem Sie wirklich nur ein requirements.txt oder Pipfile und keinen tatsächlichen Code wollen, und das scheint alles zu sein, worauf sich pipenv bisher konzentriert hat ( pipenv install -e . fällt in diese Kategorie, da pipenv immer noch Angst hat, die Paketmetadaten zu unterstützen). Obwohl das Design von pipenv mit diesem Ansatz sauberer ist, ist es für die meisten Anwendungen leider auch viel weniger nützlich, da PEP 518 beschlossen hat, zu überlegen, wie Projekte im bearbeitbaren Modus installiert werden sollen. Um pipenv weiterhin zu verwenden, bleiben wir also ziemlich auf Setuptools stecken während länger, da Sie pyproject.toml nicht verwenden können, um von Setuptools abzuweichen und trotzdem pipenv install -e . .

Es gibt derzeit keinen Standard für setup.cfg außer den Konventionen, die von distutils und setuptools festgelegt wurden. pyproject.toml ist absolut für Bibliotheksmetadaten als Nachfolger von setup.py gedacht, oder die Community hätte stattdessen Build-Anforderungen in setup.cfg gestellt.

Distutils ist Teil der Standardbibliothek und setuptools wird jetzt mit pip installiert. Es ist also ein bisschen albern zu sagen, dass es keinen Standard gibt. Ganz zu schweigen davon, dass es unter anderem den in S. 345 beschriebenen Standard für Metadaten verwendet und auch zur Angabe von Build-Anforderungen verwendet werden kann.

Die Community hätte stattdessen Build-Anforderungen in setup.cfg gestellt.

Meinen Sie die aufmunternden Autoren? Sie können sie fragen, warum sie ihre Entscheidung getroffen haben, sie skizzieren alles im Pep.

pyproject.toml beschreibt, wie ein Projekt erstellt wird (PEP 518), und ein Teil des Erstellens beschreibt Metadaten. Ich sage NICHT, dass pyproject.toml einen Standardspeicherort für diese Metadaten benötigt, aber PEP 518 verwendet diese Datei, um ein Build-Tool zu installieren, und von dort ist es sehr vernünftig zu erwarten, dass das Build-Tool eine deklarative Konfiguration von einer anderen Stelle in der Datei verwendet um zu bestimmen, wie das Projekt erstellt werden soll.

Dies wurde kürzlich auf die Mailingliste gesetzt - nichts hat irgendwo einen Standard um pyproject.toml deklariert, außer dass er zum Deklarieren der Build-Systemanforderungen verwendet wird. Alles andere ist eine Annahme; Sie können dies als "Metadaten der Bibliotheksdefinition" bezeichnen, dies ist jedoch nicht der Fall. Versuchen Sie, nur ein Build-System ohne zusätzliche Informationen zu Ihrem Projekt zu definieren (dh keine pep-345-kompatiblen Metadaten), laden Sie es auf pypi hoch und lassen Sie mich wissen, wie das geht.

Wie auch immer, zurück zu Pipenv vs Poetry - es scheint eine Idee zu geben, dass Anwendungen keine bestimmten Funktionen benötigen, die Bibliotheken erhalten, wie z. B. Einstiegspunkte, und dies ist einfach falsch. Es sollte für eine Anwendung unkompliziert sein, ein Python-Paket zu sein.

Wer sagt, dass für Anwendungen keine Einstiegspunkte erforderlich sind? Pipenv hat ein ganzes Konstrukt, um dies zu handhaben.

Um pipenv weiterhin verwenden zu können, bleiben wir noch eine Weile bei setuptools hängen, da Sie pyproject.toml nicht verwenden können, um von setuptools zu wechseln und trotzdem pipenv install -e zu verwenden.

Nicht hier folgen ... wir werden pip nicht für immer in Version 10 verkaufen lassen, ich habe unseren neuen Resolver buchstäblich beschrieben, und der eigentliche Installer greift einfach direkt auf pip zurück ... wie verhindert dies, dass Leute editierbar verwenden installiert?

Dies wurde kürzlich auf die Mailingliste gesetzt - nichts hat irgendwo einen Standard um pyproject.toml deklariert

Das ist richtig, es ist kein "Standard", aber im selben Thread erkennen Sie, dass sie durch das Aufrufen von pyproject.toml wahrscheinlich darum gebeten haben, diese Datei für andere projektbezogene Einstellungen / Konfigurationen zu verwenden.

Nach der gleichen Logik, die Sie hier aufgerufen haben:

Distutils ist Teil der Standardbibliothek und setuptools wird jetzt mit pip installiert. Es ist also ein bisschen albern zu sagen, dass es keinen Standard gibt.

pyproject.toml ist ein Standard, und die Community hat ihn als Standardspeicherort für Informationen zum Build-System und zu anderen Teilen eines Python-Projekts übernommen.

Nicht hier folgen ... wir werden pip nicht für immer in Version 10 verkaufen lassen, ich habe unseren neuen Resolver buchstäblich beschrieben, und der eigentliche Installer greift einfach direkt auf pip zurück ... wie verhindert dies, dass Leute editierbar verwenden installiert?

PEP 517 hat sich auf bearbeitbare Installationen konzentriert ... was bedeutet, dass es keine Standardmethode zum Installieren eines Projekts im bearbeitbaren Modus gibt, wenn Sie keine Setup-Tools verwenden (mit einem Konzept, das als Entwicklungsmodus bezeichnet wird und das Projekt im bearbeitbaren Modus installiert).

Distutils ist Teil der Standardbibliothek und setuptools wird jetzt mit pip installiert. Es ist also ein bisschen albern zu sagen, dass es keinen Standard gibt. Ganz zu schweigen davon, dass es unter anderem den in S. 345 beschriebenen Standard für Metadaten verwendet und auch zur Angabe von Build-Anforderungen verwendet werden kann.

Ja, es wird erwartet, dass das Build-System die in PEP 345 beschriebene PKG-INFO-Datei ausgibt. Dies ist ein Übertragungsformat, das in einer SD-Liste oder einem Rad gespeichert ist und aus einer setup.py/setup.cfg generiert wird. Es ist kein Ersatz als solche für die benutzerbezogenen Metadaten. Bei der Verwendung von pyproject.toml PEP 518 geht es darum, Alternativen zu Distutils / Setuptools als Build-System zu unterstützen. Derzeit versucht niemand, die Formate SDIST / Wheel zu ersetzen. Diese Ersatz-Build-Systeme benötigen einen Platz zum Ablegen ihrer Metadaten. Glücklicherweise hat PEP 517 den Namespace tool. für diese Systeme reserviert. Dies ist keine Annahme -

Versuchen Sie, nur ein Build-System ohne zusätzliche Informationen zu Ihrem Projekt zu definieren (dh keine pep-345-kompatiblen Metadaten), laden Sie es auf pypi hoch und lassen Sie mich wissen, wie das geht.

Wie konstruktiv.

Wer sagt, dass für Anwendungen keine Einstiegspunkte erforderlich sind? Pipenv hat ein ganzes Konstrukt, um dies zu handhaben.

Wo ist dieses Konstrukt? Ich kann nicht einmal das Wort "Eintrag" auf einer Seite der pipenv-Dokumentation unter https://pipenv.readthedocs.io/en/latest/ finden, also klingt "ein ganzes Konstrukt" ziemlich weit hergeholt? Wenn Sie bearbeitbare Installationen meinen, dann haben wir den Punkt erreicht, den ich oben gemacht habe - mit pipenv, der sich entschlossen hat, sich an pipenv install -e . zu koppeln, als einzige Möglichkeit, eine Anwendung als Paket einzubinden und zu entwickeln, für die absehbare zukünftige Unterstützung von pipenv hier ist an setuptools gekoppelt. Ich denke, die gesamte Kontroverse läuft wirklich auf diesen Punkt hinaus und die Leute (sicherlich ich) sind frustriert, dass wir jetzt Bibliotheken definieren können, die keine Setuptools verwenden, sich aber nicht mit pipenv darauf entwickeln können. Um ganz klar zu sein, ist dies nicht ausschließlich Pipenvs Schuld (PEP 518 hat beschlossen, auf bearbeitbare Installationen zu verzichten), aber seine Weigerung, das Problem anzuerkennen, war im Diskurs frustrierend, da die Poesie eine Alternative bietet, die dieses Problem auf eine Weise behandelt, die konform ist mit dem Format pyproject.toml . Pipenv sagt immer wieder, dass Poesie schlechte Entscheidungen trifft, aber nicht wirklich versucht, einen Weg nach vorne zu finden.

https://pipenv.readthedocs.io/en/latest/advanced/#custom -script-shortcuts

Bitte lesen Sie die Dokumentation.

@bertjwregeer :

pyproject.toml ist ein Standard, und die Community hat ihn als Standardspeicherort für Informationen zum Build-System und zu anderen Teilen eines Python-Projekts übernommen.

Großartig, und wir freuen uns, SDISTEN und Räder, die mit diesem System erstellt wurden, unterzubringen. Bis es einen Standard für bearbeitbare Installationen gibt, werden wir weiterhin Pip verwenden, um SDISTEN und Räder zu erstellen und die Abhängigkeitsauflösung auf diese Weise zu handhaben. Bitte lesen Sie meine Antworten vollständig. Die Autoren und Betreuer von pip, der fraglichen Peps sowie ich und @uranusjr kennen die Unterschiede zwischen bearbeitbaren Installationen und die Auswirkungen ihrer

Ich habe schon gesagt, das ist nicht richtig. Wenn Sie tatsächlich an der Implementierung interessiert sind und ein produktives Gespräch führen, bin ich froh darüber. Wenn Sie einfach hier sind, um zu sagen, dass wir nicht wissen, was wir tun, aber nicht daran interessiert sind, zuerst zu erfahren, was wir tun, ist dies Ihre einzige Warnung. Wir sind Freiwillige mit begrenzter Zeit und ich praktiziere eine 0-Toleranz-Richtlinie für toxische Engagements. Ich gebe nicht vor, dass meine Arbeit perfekt ist, und ich gebe nicht vor, dass pipenv perfekt ist. Gerne bringe ich meine Zeit und Mühe in diese Art von Diskussionen ein. im Gegenzug bitte ich darum, dass sie respektvoll behandelt werden, dass sie sich an Fakten halten und dass diejenigen, die daran teilnehmen, auch bereit sind, mich zu lernen, zuzuhören und anzuhören. Wenn Sie nur zur Seifenkiste hier sind, müssen Sie eine andere Plattform finden; Dies ist ein Issue-Tracker. Ich werde es nach Bedarf moderieren.

Diese Diskussion ist völlig unangebracht . Wenn jemand etwas Konstruktives zu diesem Thema zu sagen hat, können Sie diese Diskussion gerne fortsetzen. Wenn jemand Probleme oder Fragen zu unseren Build-System-Implementierungen hat, öffnen Sie bitte ein neues Problem. Wenn Sie Probleme mit unserer Dokumentation haben, akzeptieren wir viele Pull-Anfragen rund um die Dokumentation und sind uns bewusst, dass diese Arbeit benötigt. Bitte verschieben Sie die gesamte Diskussion auf neue Themen für diese Themen. Und bitte beachten Sie: Es gelten weiterhin dieselben Regeln - dies ist keine Seifenkiste, sondern ein Issue-Tracker.

https://pipenv.readthedocs.io/en/latest/advanced/#custom -script-shortcuts
Bitte lesen Sie die Dokumentation.

Einstiegspunkte sind ein allgemeineres Konzept als nur Konsolenskripte, und dieser Link ist völlig falsch, wenn es darum geht, diese Bedenken auszuräumen. <soapbox> Ban away - Sie sind hier nicht der einzige Betreuer großer Open Source-Projekte, und keiner meiner Kommentare war ein persönlicher Angriff auf Sie oder das Projekt. Die Leute, die hier kommentieren, tun dies, weil sie pipenv verwenden wollen und viel von dem schätzen, was es tut. Mein Kommentar war nicht der erste Off-Topic-Beitrag in diesem Thread, aber der einzige, der markiert ist. Ihre snarky Kommentare, die darauf hinweisen, dass Sie denken, ich weiß nicht, wovon ich spreche, sind peinlich und giftig.

In dem Projekt, das wir pflegen, können wir Seifenkisten. Und ja, pip unterstützt alle kompatiblen Build-Systeme, von denen Sie beide zu wissen scheinen, dass sie Verbrauchsmaterial-Metadaten erzeugen. Da pipenv pip als Backing-Tool verwendet, um den Installationsprozess voranzutreiben, wie ich beschrieben habe, unterstützt pipenv alle kompatiblen Systeme Werkzeuge. Das habe ich schon gesagt.

Also ja, bitte nehmen Sie Ihre Toxizität woanders hin. Ihre Einstellung ist hier nicht willkommen. Letzte Warnung. Anhaltende Versuche, Konflikte anzuregen, werden nicht toleriert.