Pip: Neuer Resolver: Rollout, Feedback-Schleifen und Entwicklungsablauf

Ich weiß nicht, wie Sie es geplant haben, aber ein Kommentar ist, dass ich Sie ermutigen möchte, so viel Code wie möglich zwischen dem neuen Code und dem aktuellen Code zu teilen und den aktuellen Code während der Arbeit umzugestalten ermöglichen mehr gemeinsame Nutzung zwischen den neuen und aktuellen Codepfaden.

Ein Grund dafür ist, dass, wenn Sie mehr Code teilen, die Wahrscheinlichkeit eines Bruchs geringer ist, wenn Sie das neue Verhalten ein- und ausschalten, da Sie diesen gemeinsam genutzten Code in beiden Zuständen ausführen und nicht so haben viele potenzielle Unterschiede im Verhalten zu bewältigen.

Dies würde CTAs an Benutzer beinhalten, um sie zu bitten, es auszuprobieren und Feedback zu geben

Unsere Erfolgsbilanz beim Einholen von Vorab-Feedback zu neuen Funktionen war ziemlich schlecht. Wir haben Betaversionen ausprobiert, neue Funktionen mit „Opt-out“-Flags veröffentlicht, die Benutzer verwenden können, wenn sie auf Probleme stoßen, große Werbekampagnen für Breaking Changes, und keine davon scheint funktioniert zu haben.

Mein persönliches Gefühl ist, dass "Stellen Sie es zur Verfügung und fragen Sie nach Feedback" eine interessante Variation dessen ist, was wir zuvor versucht haben, aber letztendlich wird es keinen großen Unterschied machen. Zu viele Leute verwenden den neuesten Pip mit Standardoptionen in ihren automatisierten Build-Pipelines und testen nicht, bevor sie zu einer neuen Pip-Version wechseln (wir haben dies bei PEP 517 gesehen).

Ich frage mich - könnten wir einen PSF-Zuschuss erhalten, um Ressourcen zu erhalten, um entweder eine große "reale" Testübung für dieses Feature durchzuführen oder (noch besser) eine Testinfrastruktur für uns zu entwickeln? Ein solches Projekt könnte einen Aufruf für Projekte beinhalten, um uns ihre Arbeitsabläufe und Konfigurationen mitzuteilen, damit wir Testpfade einrichten können, die sicherstellen, dass neue Pip-Versionen sie nicht beschädigen. Oder verwenden Sie einfach ein Stipendium, um jemanden mit Erfahrung im Kommunikationsaspekt zu gewinnen, um Betatester für neue Funktionen zu gewinnen, um uns bei der Einrichtung eines besseren Benutzertestprogramms zu helfen?

In Bezug auf Git/GitHub ist dies wahrscheinlich die erste „experimentelle“ Feature-Implementierung innerhalb von pip

Ich bin mir nicht 100% sicher, was du damit meinst. Wir hatten in der Vergangenheit sicherlich neue Funktionen, die hinzugefügt wurden, während der „alte Weg“ noch vorhanden war. Wir neigen nicht dazu, sie "standardmäßig deaktiviert, zum Ausprobieren aktivieren" zu lassen, wenn Sie das meinen, aber das liegt hauptsächlich daran, dass wir nie einen guten Weg gefunden haben, Feedback zu erhalten (siehe oben).

Ich habe ungefähr 60 Minuten damit verbracht, diesen einen Beitrag zu schreiben, also werde ich mir jetzt Orte in New York ansehen! Wenn Sie keine schnelle Antwort von mir sehen, liegt das daran, dass ich im Touristenmodus bin.

Ich möchte Sie ermutigen, zu versuchen, Code so weit wie möglich zwischen dem neuen Code und dem aktuellen Code zu teilen, und den aktuellen Code während der Arbeit umzugestalten, um mehr gemeinsame Nutzung zwischen dem neuen und dem aktuellen Codepfad zu ermöglichen.

Bestimmt! Das ist zu 80 % der Grund, warum ich #5051 voranstelle – ich beabsichtige, einen Großteil der technischen Schulden, die wir in unserer Build-Logik angesammelt haben, zu begleichen, damit es einfacher wird, sie (alles?) wiederzuverwenden. Ein Teil des Codes muss :fire: sein, und ich stimme zu, dass der Rest definitiv so oft wie möglich wiederverwendet werden sollte.

Wir haben nicht dazu tendiert, sie "standardmäßig deaktiviert zu lassen, um sie auszuprobieren" zu lassen, wenn Sie das meinen

Ja, in der Tat. Ich weise hier auch auf den Entwicklungsfluss hin – meiner Meinung nach wäre es in Ordnung, leere Infrastruktur zusammenzuführen (Klassen mit einer Reihe von Methoden, die nur raise NotImplementedError() sind und in nachfolgenden PRs konkretisiert werden) oder nicht decken alle Fälle (unausgegorene Implementierung) in den master -Zweig ab, solange dieser nur hinter dem Flag verwendet wird, das ausdrücklich als "experimentell/alpha" gekennzeichnet ist.

Re: Rückmeldung

Ich bin jung, dumm und optimistisch – ich möchte diese Einführung zu einem Opt-in machen, um proaktives Feedback zu erhalten und darauf zu reagieren. Mit "proaktiv" meine ich von Leuten, die bereit sind, sich etwas mehr Zeit zu nehmen, um Alpha-/Beta-Funktionen auszuprobieren und uns darüber zu informieren, wie es ist. Ich denke, wenn wir genug Lärm machen und die Leute strategisch ansprechen/erreichen, können wir gutes "proaktives" Feedback von Leuten bekommen, die die Zeit und Energie haben, neue Funktionen auszuprobieren, um die Details/Probleme auszubügeln.

Wenn ich mir unsere jüngsten „großen“ Änderungen anschaue, denke ich, dass das meiste Feedback, das wir erhalten haben, reaktiv war – von Benutzern, die Probleme mit ihren Arbeitsabläufen erkannten, als sie brachen, und uns dann darauf ansprachen, um uns darüber zu informieren. Viele von ihnen hatten vielleicht nicht die Zeit, die Details der neuen Funktionalität auszubügeln, was viel Reibung verursacht. Diese kosten uns auch viel von unserem „Churn-Budget“ [1], von dem ich nicht mehr ausgeben möchte, da Python Packaging sowieso nicht mehr viel übrig hat [2].

FWIW, ich plane, einige Ideen aus dem PyPI-Start zu übernehmen, wie das Erstellen von Blog-Beiträgen an gut sichtbaren Orten (dh nicht in meinem persönlichen Blog), möglicherweise Podcasts, gut getimte umsetzbare E-Mails usw. Ich suche auch nach mehr Stand der Technik /wege zur Kommunikation. Eines der (vielen!) Dinge, die ich bei PyCon gelernt habe, war, dass es Kanäle gibt, die wir nicht verwenden, die helfen, Informationen zu verbreiten, aber nicht versuchen zu prüfen, ob wir welche zu verbreiten haben.

Um es klar zu sagen, ich kritisiere nicht den Rollout-Ansatz, den wir für PEP 517 gewählt haben, ich denke, es läuft gut, besonders angesichts der Tatsache, dass wir alle Freiwillige sind. Ich versuche zu sehen, was wir lernen können und umsetzbare Elemente, um zu versuchen, die Probleme zu vermeiden, die wir hatten. Die meisten dieser Punkte erfordern mehr Arbeit von den Betreuern, und der Hauptgrund, warum ich überhaupt so viel Zeit damit verbringe, darüber nachzudenken, ist, dass ich dies als eine unterhaltsame Lernübung betrachte, wie man Änderungsmanagement durchführt.

Re: Zuschüsse

Ja, ich denke, wir können definitiv einen Zuschuss/eine erfahrenere Person gebrauchen, die uns dabei hilft, die Kommunikation, Rollouts und die Testinfrastruktur herauszufinden. Das erfordert jedoch jemanden, der die Arbeit zum Verfassen von Stipendien übernimmt und konkretere Pläne ausarbeitet, als ich jetzt machen kann, da ich keine stabilere Anzahl von Stunden / Woche habe, die ich garantieren kann.

FWIW, PSF hat einen laufenden Vertrag, um bei der PyPA/Packaging-bezogenen Kommunikation mit Changeset Consulting zu helfen, also können wir das vielleicht nutzen?

Ich erwähne absichtlich keine Personen, da dies ziemlich früh in der Planung ist, um mehr Personen in die Konversation einzubeziehen.

Fußnoten:

1. Ein wirklich schöner Begriff, den @ pganssle verwendet hat und den ich definitiv verwenden werde.
2. Aus diesem Grund habe ich #3164 auf Eis gelegt, obwohl ich eine Implementierung des dort vorgeschlagenen "pip-cli"-Pakets habe und einen vernünftigen Konsens darüber habe, wie der Rollout aussehen soll.

Ich bin jung, dumm und optimistisch

:-) Und ich bin manchmal zu alt, müde und zynisch. Lassen Sie uns mit Ihrer Philosophie gehen, es klingt viel besser :-)

Bestimmt! Das ist zu 80 % der Grund, warum ich #5051 voranstelle – ich beabsichtige, einen Großteil der technischen Schulden, die wir in unserer Build-Logik angesammelt haben, zu begleichen, damit es einfacher wird, sie (alles?) wiederzuverwenden.

Toll!

Gerade aus dem IRC :

[sumanah] pradyunsg: Gibt es irgendetwas, was wir, die Pip- und Verpackungs-Community, tun können, um Ihnen dabei zu helfen, mehr Arbeit am Resolver schneller zu erledigen?
....
[pradyunsg] Im Moment würden mir Beiträge auf https://github.com/pypa/pip/issues/6536 wahrscheinlich helfen, herauszufinden, wie ich an die Arbeit herangehen / Feedback von Leuten erhalten usw.
....
[sumanah] pradyunsg: re: New Resolver: Rollout, Feedback Loops and Development Flow #6536 – die Eingabe, die Sie wünschen, ist so etwas wie: Ist der Feature-Flag-Ansatz eine gute Idee? Ist es eine gute Idee, Feedback über einen anderen Mechanismus als die Pip-GitHub-Probleme zu erhalten? Ist es eine gute Idee, ein Stipendium oder ähnliches zu erhalten, um reale manuelle Tests und eine robuste Testinfrastruktur und/oder proaktive Kommunikation aufzubauen?
...
[pradyunsg] Ja – ob die Ideen, die ich vorschlage, gut sind. Auch alle zusätzlichen Ideen/Ansätze/Gedanken, die dazu beitragen könnten, dass die Einführung und das Feedback reibungsloser verlaufen, wären großartig.

So:

Ist der Feature-Flag-Ansatz eine gute Idee? Ja.

Ist es eine gute Idee, Feedback über einen anderen Mechanismus als die Pip-GitHub-Probleme zu erhalten? Ja. Wir sollten automatisierte Wege finden, um weniger strukturierte Fehlerberichte von weniger erfahrenen Benutzern zu akzeptieren.

Würde eine robustere Testinfrastruktur helfen? Ja, sehr viel, und hier können unsere Sponsoren uns vielleicht helfen.

Könnte Changeset (ich) im Rahmen des bestehenden Vertrags mit PSF zur Unterstützung bei der PyPA-Koordination/Kommunikation pip mit proaktiver Kommunikation helfen, um uns systematischere manuelle Tests in der realen Welt zu ermöglichen? Angenommen, ich habe noch Stunden in meinem Vertrag, wenn wir mit dieser Einführung beginnen möchten, ja.

Ist es eine gute Idee, ein Stipendium oder ähnliches zu erhalten, um mehr Hilfe bei der Benutzererfahrung, Kommunikation/Werbung und Tests zu erhalten? Ja. Die PSF-Förderungen wären potenziell von Interesse , ebenso wie NLNet-Förderungen (für Anträge unter 30.000 Euro ), möglicherweise die Chan Zuckerberg-Stipendien für essentielle Open-Source-Software für die Wissenschaft und Mozillas MOSS . Die Verpackungs-AG kann der eingetragene Antragsteller sein. Wenn @pradyunsg oder @pfmoore ein "Ja, das klingt interessant"-Nicken geben möchte, kann ich anfangen, diese Möglichkeiten mit der WG zu untersuchen.

Wenn @pradyunsg oder @pfmoore ein "Ja, das klingt interessant"-Nicken geben möchte,

Klingt für mich auf jeden Fall interessant :-)

@pradyunsg oder @pfmoore möchte ein "Ja, das klingt interessant"-Nicken geben

_nickt_ ja das klingt interessant

Würde eine robustere Testinfrastruktur helfen? Ja, sehr viel, und hier können unsere Sponsoren uns vielleicht helfen.

@brainwane Ebenfalls relevant ist hier https://github.com/pypa/integration-test. Ich denke, diese Einrichtung ist ein weiterer potenzieller Finanzierungsbereich – wir sollten dies zu https://wiki.python.org/psf/Fundable%20Packaging%20Improvements hinzufügen.

OK! Ich habe begonnen, mit der PSF und den Leuten der Chan-Zuckerberg-Initiative über die Beantragung eines CZI-Stipendiums über die Packaging Working Group zu sprechen. Ich habe auf der Seite Fundable Packaging Improvements einige Details darüber hinzugefügt, warum der neue Pip-Resolver wichtig ist, und das Projekt integration-test zu dieser Liste hinzugefügt. Und ich habe damit begonnen, Namen von Experten für Benutzererfahrung zu sammeln, die in der Lage sind, unsere komplizierte Paketverteilungs-/Installations-Toolkette auf Befehlszeile zu untersuchen und mit Benutzern zu sprechen, um ihr mentales Modell dessen zu verstehen, was passiert und was passieren sollte , und Betreuer beraten.

Wenn wir Geld über Stipendien von MOSS, CZI oder NLNET bekommen, denke ich, dass wir das Geld bekommen ... wahrscheinlich frühestens im Oktober. Ein Zuschuss direkt von der PSF wäre wahrscheinlich schneller, aber "Unser derzeitiger Fokus liegt auf Python-Workshops, Konferenzen (insbesondere für finanzielle Unterstützung) und Bemühungen um Python-Diversität/Inklusivität."

Eine Überlegung ist, dass ich weiß, dass Brett und die Leute drüben im Lenkungsrat darüber sprechen, in Projektmanagement zu investieren und nach bezahlten Ressourcen für die Verwaltung dieser Projekte zu suchen (Triage, Projektmanagement usw.), und sie sprechen mit der PSF direkt. Es kann sich lohnen, die Hand zu reichen und herauszufinden, was sie tun oder denken, da ich einige Gespräche über langfristige Nachhaltigkeit gehört habe und es eine gute Sache wäre, daran beteiligt zu sein.

Feature-Flags sind gut, Opt-Ins sind gut. Eine Sache, die Sie in Betracht ziehen könnten, ist, ob Sie Benutzer nach dem Zufallsprinzip auffordern könnten, den Resolver auszuprobieren (z. B. sehr, sehr, sehr selten und nur für jeweils eine Installation, dh sie nicht zwingen, ihn dauerhaft einzuschalten). Dann könnten Sie angeben, wie hilfreich der Resolver war (z. B. was hat er für sie getan? Auf welche Konflikte ist er gestoßen und hat er gelöst?)

Leute, die zum Beispiel von Javascript oder Rust kommen, werden auch eine Art Sperrdatei erwarten, also sollte man das vielleicht in Betracht ziehen ...

Tut mir leid, dass ich einspringen muss, ich bin froh, dass es vorangeht!

Mein persönliches Gefühl ist, dass "Stellen Sie es zur Verfügung und fragen Sie nach Feedback" eine interessante Variation dessen ist, was wir zuvor versucht haben, aber letztendlich wird es keinen großen Unterschied machen. Zu viele Leute verwenden den neuesten Pip mit Standardoptionen in ihren automatisierten Build-Pipelines und testen nicht, bevor sie zu einer neuen Pip-Version wechseln (wir haben dies bei PEP 517 gesehen).

Als einer der Leute, die aus genau diesem Grund von einigen PEP 517-Problemen gebissen wurden, würde ich gerne eine Opt-in-Methode zum Testen von Dingen sehen. Aber ich weiß nur über solche Dinge Bescheid, weil ich alle Nachrichtenquellen für Python-Pakete abonniert habe, die ich nach der --no-use-pep517 -Flag-Ausgabe finden konnte. Was ich damit sagen will ist, dass es schwierig ist, diese Art von Neuigkeiten zu verbreiten, und das ist wahrscheinlich der Grund, warum Feedback schwer zu bekommen ist.

Ich denke, dass mehr Leute daran interessiert wären, wenn die Informationen besser verbreitet werden könnten. Ist es das, was die von Ihnen gesuchten Ressourcen zulassen würden?

Um mit dem fortzufahren, was jriddy sagt, ich glaube auch, dass es wirklich schwierig sein wird, Leute dazu zu bringen, verschiedene Feature-Flags zu testen, wenn sie davon wissen müssen, Änderungen an ihrem CI-Setup für jedes neue Flag vorzunehmen usw.

Was jedoch viel machbarer erscheint, ist, wenn es nur _ein_ Feature-Flag gibt, über das man Bescheid wissen muss, um zu testen, "was als nächstes kommt" in Bezug auf Änderungen, die getestet werden müssen. Dann könnten Personen und Unternehmen ihr CI so einrichten, dass es auch ausgeführt wird (ohne dass Builds aufgrund von Fehlern fehlschlagen). Ich denke an etwas Ähnliches wie Rust, wo diese Art von Änderungen im „Beta“-Kanal der Toolchain backen und es einfach ist, einen anderen CI-Kanal einzurichten, um Dinge auf der Beta-Toolchain auszuführen und Fehler an jemanden zu senden.

Das Wichtigste ist, dass dieses Setup _nur einmal_ erlernt und durchgeführt werden muss, anstatt sich ständig über neue individuelle Feature-Flags zu informieren, CI-Setups zu modifizieren oder sie manuell zu testen.

Was jedoch viel machbarer erscheint, ist, wenn es nur _ein_ Feature-Flag gibt, über das man Bescheid wissen muss,

Existiert das nicht gewissermaßen schon in Form von --pre ? Könnte der Beta-Release-Kanal für Pip nur eine Frage des Ausführens von pip install --upgrade --pre pip sein?

Tut mir leid, dass ich einspringen muss, ich bin froh, dass es vorangeht!

@techalchemy bitte, ausgerechnet _du_ musst es definitiv nicht bereuen, dass du dich an dieser Diskussion beteiligt hast.

Ist es das, was die von Ihnen gesuchten Ressourcen zulassen würden?

Bis zu einem gewissen Grad, ja.

reg: beta releases/"channel" für pip

Danke, dass Sie sich bei @jriddy und @chrish42 gemeldet haben. Obwohl ich denke, dass dies im Allgemeinen definitiv ein nützliches / wichtiges Gespräch ist, halte ich es für dieses Thema auch für etwas OT. Trotzdem antworte ich hier einmal; Wenn wir das weiter diskutieren wollen, eröffnen wir ein neues Thema.

Wir haben das in der Vergangenheit versucht – zuletzt mit Pip 10 – aber es hat nicht gut funktioniert. Ich bin etwas skeptisch, wie gut das auch in Zukunft funktionieren könnte, aber ich kann mir auch vorstellen, dass einige Änderungen an unserem Prozess dazu führen könnten, dass dies für uns reibungslos funktioniert. Vielleicht könnten wir eine "nur Beta"-Reihe von Features machen oder so? Als Syntax dafür hatte ich mir in #5727 -X all vorgestellt. Vielleicht könnten wir das als Teil dieses Rollout-Plans aufgreifen? Idk. Wir müssen Zeit und Energie investieren, um das herauszufinden. :)

Wie in https://github.com/pypa/packaging-problems/issues/25#issuecomment -520167480 erwähnt, halte ich es für wichtig, eine konsolidierte Erklärung darüber zu haben, wie ein Solver die Pip-Erfahrung ändert. Viele Leute werden von der Umstellung auf ein starreres System frustriert sein (obwohl die Dinge insgesamt zuverlässiger sein sollten, werden sie an Stellen blockiert, an denen sie derzeit nicht blockiert werden.

Eine zentrale Erklärung dafür zu haben, wie sich die Dinge geändert haben und warum es eine gute Änderung ist, wird es viel einfacher machen, auf diese wütenden Menschen zu reagieren. Posten Sie einen Link und sehen Sie, ob sie weitere Fragen haben.

Die Vorabversion ist eine gute Idee. In conda haben wir einen Vorabversionskanal, conda-canary. Wir ermutigen die Leute, einen CI-Job einzurichten, um gegen Canary auf eine Weise zu laufen, die ihnen hilft zu sehen, ob Conda-Änderungen sie kaputt machen werden. Idealerweise lassen sie es uns wissen, bevor wir diese Version veröffentlichen. Dieser Kanal war ein ziemlich kläglicher Fehlschlag. Die einzige Zeit, in der die Leute es wirklich zu verwenden scheinen, ist, wenn sie die neueste Version erhalten möchten, um einen Fehler zu beheben, mit dem sie zu kämpfen haben. Wir erhalten nicht viele Berichte von unseren beabsichtigten Early Adopters. Ich denke immer noch, dass die Vorabversion eine gute Idee ist, denn wenn eine Version schlecht läuft und die Leute wütend auf Sie sind, weil Sie ihre 700 verwalteten Knoten kaputt gemacht haben, können Sie sagen: „Nun, es war eine Woche lang verfügbar, bevor wir es veröffentlicht haben. Warum nicht Testen Sie diese Dinge, bevor Sie sie auf 700 Knoten ausrollen?" Sie geben den Menschen die Möglichkeit, Dinge besser funktionieren zu lassen. Helfen Sie ihnen zu erkennen, dass die Weitergabe dieser Gelegenheit für sie auf der ganzen Linie mehr Schmerz bedeutet. Es ist eine lohnende Investition für sie, und wenn sie es als Teil ihres CI tun, kostet es sie abgesehen von der Einrichtung keine Zeit.

Bezüglich des Flags: Ich denke, es ist besser, eine Konfigurationsoption zu haben (vielleicht zusätzlich zu einem Flag). Ich würde nicht die ganze Zeit eine Flagge überholen wollen. Ich bin mir nicht sicher, ob pip diese Fähigkeit hat - vielleicht sagen Sie Leuten, die einen dauerhafteren Schalter wünschen, die entsprechende env var zu verwenden?

Bezüglich der Flagge:

Die CLI-Optionen von pip werden automatisch einer Konfigurationsdateioption und einer Umgebungsvariablen mit den entsprechenden Namen zugeordnet.

@msarahan Danke fürs Mitmachen, sehr geschätzt! :)

In Bezug auf die Option "Lass mich tun, was ich will", um defekte Abhängigkeiten zu ignorieren, denke ich, dass es wünschenswert wäre, das Feature-Flag so zu strukturieren, dass es auch als Opt-out dienen kann, nachdem der Resolver standardmäßig aktiviert wird (z mit --avoid-conflicts als Opt-in, eventuell zu --no-avoid-conflicts als Opt-out wechseln, aber von Anfang an beide Optionen akzeptieren)

Sie sollten auch überlegen, wie --ignore-installed mit dem Solver interagiert - wenn er bestanden ist, sollten Sie wahrscheinlich alle Anforderungen für bereits installierte Pakete ignorieren.

Darüber hinaus ist es ein ausgezeichneter Weg, Dinge als kleinere Refactoring-Patches zu handhaben, um die Integration des Resolvers zu vereinfachen (das ist der Ansatz, der die neue Konfigurations-API für CPython möglich gemacht hat: viel privates Refactoring, das schließlich stabil genug war, um veröffentlicht zu werden).

@ncoghlan Was bedeutet "Ablehnen" des Resolvers? Das vollständige Vermeiden der Abhängigkeitsauflösung (und damit des Resolvers) ist --no-deps . Ich verstehe, dass ein "Versionskonflikte in diesem Paket ignorieren" oder etwas in dieser Richtung erforderlich ist.

Ich persönlich sehe keinen Sinn darin, die „Keep first seen“-Auflösungslogik länger als eine Übergangszeit zu einem neuen Resolver beizubehalten.

Wenn es jedoch Anwendungsfälle gibt, die diese beiden Optionen nicht abdecken würden, würde ich wirklich gerne etwas darüber erfahren. :)

Allgemeiner gesagt, wenn es Workflows gibt, die Probleme mit dem Verhalten eines strikten Resolvers haben, bin ich neugierig zu wissen, wie diese so früh wie möglich aussehen, um herauszufinden, ob/wie sie unterstützt werden können.

Ich persönlich sehe keinen Sinn darin, die „Keep first seen“-Auflösungslogik länger als eine Übergangszeit zu einem neuen Resolver beizubehalten.

IDK, ich benutze dieses "Feature", um ein paar ziemlich verrückte Sachen mit Builds zu machen, wie ...

# install just the packages I've built specifically
pip install --no-index --no-deps --find-links=/path/to/my/local/build/cache -r local-reqs.txt

# ...snip to later in a dockerfile, etc...

# install the deps from public PyPI
pip install -r local-reqs.txt

In diesem Fall bitte ich darum, meine Abhängigkeiten aufzulösen, nachdem ich einige sehr vordefinierte Pakete von einem lokalen Steuerhaus installiert habe. Ich nehme an, ich könnte meine genauen Versionen in diese local-reqs-Datei einlesen, um einen Resolver glücklich zu machen, aber ich fand das aktuelle Verhalten von pip tatsächlich ziemlich nützlich, um diese Art von willkürlichen Build-Injektionsschritten zu ermöglichen. Könnte aber ein Fall des Arbeitsablaufs zum Erhitzen der Leertaste sein, gebe ich zu.

Aber vielleicht hat das Verhalten der "naiven Auflösung" noch einen Nutzen.

Ich stimme @pradyunsg zu. Ich glaube nicht, dass es praktikabel ist, den vorhandenen Code und einen neuen Resolver auf unbestimmte Zeit beizubehalten. Als Pip-Betreuer habe ich sicherlich kein Interesse daran.

Aus Sicht eines Endbenutzers akzeptiere ich, dass es durchaus seltsame Szenarien geben könnte, in denen der neue Resolver möglicherweise nicht das Richtige tut. Und ein Notfall-Flag "Gib mir das alte Verhalten zurück" ist ein wichtiger Übergangsmechanismus (obwohl es fraglich ist, ob "vorübergehend auf die vorherige Version von pip zurücksetzen" nicht genauso gut ist - obwohl Dinge wie die gemeinsame Verwendung von CI that verwendet automatisch den neuesten Pip, was die Befürwortung dieser Option problematisch macht). Aber warum sollten wir langfristig das aktuelle Verhalten beibehalten? Ich kann mir folgende Hauptsituationen vorstellen:

1. Resolver-Fehler. Offensichtliche Möglichkeit, einfache Lösung - Korrigieren Sie den Fehler in der nächsten Version von pip.
2. Fälle, in denen der alte Resolver falsch ist (erzeugt Ergebnisse, die die Einschränkungen nicht erfüllen). Wir beabsichtigen nicht, das in Zukunft zu unterstützen, sicher? (Zumindest nicht durch etwas weniger Extremes als den Benutzer, der festhält, was er möchte, und --no-deps verwendet, um den Resolver auszuschalten).
3. Fälle, in denen der alte und der neue Resolver unterschiedliche Ergebnisse liefern, die beide die gegebenen Einschränkungen erfüllen. Benutzer können Einschränkungen hinzufügen, um das alte Ergebnis zu erzwingen (wenn sie dies nicht können, bringt uns das zurück zu (2)). Wir sollten ihnen Zeit dafür geben, aber dann den alten Resolver löschen, genau wie jede andere veraltete Funktionalität.
4. Ein Grenzfall, den wir für zu komplex/seltsam halten, um ihn zu unterstützen. Das ist wie (3), aber wo wir nicht behaupten, dass der neue Resolver das "richtige" Ergebnis liefert. Benutzer können weiterhin Einschränkungen ändern, um den seltsamen Fall zu vermeiden, oder --no-deps anheften und verwenden. Aber letztendlich sagen wir "Tu das nicht", und wenn Benutzer diese Nachricht ignorieren, entfernen wir irgendwann wieder den alten Resolver mit der Aufschrift "Wir haben dich gewarnt".

Gibt es noch andere, die ich übersehen habe? Insbesondere dort, wo es nicht möglich ist, den alten Resolver zu verwerfen und dann zu entfernen?

Übrigens, wo ist der beste Ort, um „Hier ist ein Grenzfall, an den ich gedacht habe“-Szenarien zu posten, damit sie nicht verloren gehen? Ich denke, es wäre nützlich, so viele seltsame Situationen wie möglich im Voraus zu sammeln, um schon früh mit dem Schreiben von Testfällen beginnen zu können :-)

PS Wir sollten wahrscheinlich auch als Teil der Vorbereitungsarbeit für den neuen Resolver untersuchen, was die "typischen" Einschränkungsprobleme sind (basierend auf dem, was auf PyPI ist). Für meinen Teil kommt es ziemlich selten vor, dass ich etwas Komplexeres als "pip install". Es wäre eine Schande, sich in den komplexen Fällen so zu verzetteln, dass wir die überwiegende Mehrheit der einfacheren aus den Augen verlieren.

1. Resolver ist zu langsam (siehe Conda). Wenn ich zwischen einem 20-Minuten-Resolver oder dem aktuellen Verhalten wählen muss, möchte ich oft das aktuelle Verhalten (oder es zumindest versuchen; in vielen Fällen wird es passieren, dass es ein gutes Ergebnis liefert).

2. Metadaten falsch. heute kein so großes Problem, aber es ist leicht, sich Fälle vorzustellen, die lösbar sein sollten, es aber nicht sind. PyPI-Metadaten sind in einem schlechteren Zustand als Conda/Conda-Forge-Metadaten, und es ist bereits ein Problem für Conda. Wenn es falsch ist und ich als Benutzer keine Lösung bekomme, möchte ich ein Opt-out bekommen.

@rgommers Für 6 könnte die Stiloption "Versionskonflikte in diesem Paket ignorieren" funktionieren, oder?

Danke, @rgommers - das sind gute Punkte.

Resolver ist zu langsam, würde ich als Resolver-Bug werten. Wenn es in einfachen Fällen keine ausreichend leistungsfähigen Ergebnisse liefern kann, ist das meiner Meinung nach nicht zweckmäßig. Wenn Sie andererseits ein massiv komplexes Beschränkungsnetzwerk haben, das mit einem vollständigen Resolver länger dauert (ich hoffe, 20 Minuten sind übertrieben, das halte ich unter keinen Umständen für akzeptabel!), dann kommen wir in "Dinge, die wir als zu komplex betrachten, um das Territorium zu unterstützen. Anders ausgedrückt: Hat jemand versucht, Conda zu bitten, einen "quick and dirty" ungenauen, aber schnellen Resolver bereitzustellen? Wenn sie das nicht tun (und ich bin mir ziemlich sicher, dass sie es nicht tun würden), warum ist es dann vernünftig, von Pip zu erwarten?

Schlechte Metadaten sind definitiv etwas, das ich als "das würden wir nicht unterstützen" betrachten würde (denken Sie daran, ich spreche hier von "nach einer Verfallszeit"!). Benutzern Zeit zu geben, Metadaten zu reparieren, und eine Escape-Klausel-Option „Versionskonflikte in Paket X ignorieren“ bereitzustellen, ist meiner Meinung nach ausreichend. Es sollte nicht erwartet werden, dass wir alle alten Maschinen behalten, nur weil einige Leute ihre Metadaten nicht reparieren.

Aber ja, die Bekanntmachung der Tatsache, dass wir gute Metadaten brauchen, weil ein genauer Resolver der Regel „Garbage in, Garbage out“ folgt, und die Überwachung, wie die Leute auf diese Nachricht reagieren, ist ein wichtiger Teil des Rollout-Prozesses.

Ich bitte darum, meine Abhängigkeiten aufzulösen, nachdem ich einige sehr vordefinierte Pakete von einem lokalen Steuerhaus installiert habe.

@jriddy Die Auflösungsstrategie "vorhandene Installation verwenden, falls kompatibel" funktioniert dafür.

wo ist der beste Ort, um „Hier ist ein Grenzfall, an den ich gedacht habe“-Szenarien zu posten, damit sie nicht verloren gehen?

https://github.com/pradyunsg/zazo/

Für 6 könnte die Stiloption "Versionskonflikte in diesem Paket ignorieren" funktionieren, richtig?

ja, das klingt nach der richtigen Option

(Ich hoffe, 20 Minuten sind übertrieben, ich halte das unter keinen Umständen für akzeptabel!), dann kommen wir in das Gebiet "Dinge, die wir für zu komplex halten, um sie zu unterstützen". Anders ausgedrückt: Hat jemand versucht, Conda zu bitten, einen "quick and dirty" ungenauen, aber schnellen Resolver bereitzustellen? Wenn sie das nicht tun (und ich bin mir ziemlich sicher, dass sie es nicht tun würden), warum ist es dann vernünftig, von Pip zu erwarten?

Es gibt eine Menge Leute, die sich über die Leistung von conda beschweren, und sie hören zu - aber es ist eine Menge Arbeit, siehe ihre letzten Blogbeiträge. Ich weiß nicht, ob es eine schnelle und schmutzige Conda-Option geben wird. Es gibt jedoch verwandte Lösungen (Hacks) wie conda-metachannel , mit denen Sie den Abhängigkeitsgraphen beschneiden können (Pakete manuell einschließen/ausschließen), um schneller eine Lösung zu erhalten. Also ich denke das geht in die gleiche Richtung.

Denken Sie jedoch daran, dass dies _definitiv_ erforderlich sein wird, es sei denn, Sie:

• machen auf Anhieb einen viel besseren Job als Conda (nicht allzu wahrscheinlich, es ist nicht so, dass diese Typen nicht wissen, was sie tun - es ist nur ein wirklich haariges Problem).
• nur kleinere Probleme zu lösen haben (hoffentlich nicht wahr, PyPI ist groß und mit guten Metadaten sollten die Probleme groß sein)

Schlechte Metadaten sind definitiv etwas, das ich als "das würden wir nicht unterstützen" betrachten würde.

Meinetwegen. Die ganze Haltung zu "wir erzwingen keine korrekten Metadaten" hilft hier jedoch nicht weiter. Es sei denn, das hat sich kürzlich geändert? (und ich weiß, es ist eine PyPI-Sache, keine Pip-Sache - aber es ist verwandt).

Ich bin mir nicht sicher, ob Sie wirklich die Möglichkeiten haben, die Sie zu haben glauben.

Was macht ein schneller und schmutziger Resolver anders als ein genauer? Was lässt es fallen, um schneller zu sein? Einschränkungen sind Einschränkungen – sie kommen nicht in Noten. Entweder du befriedigst sie oder du tust es nicht. Vielleicht können Sie sie erst nach Namen starten, dann nach Version usw.

Wenn sich Leute darüber aufregen, dass Conda langsam ist, liegt das im Grunde immer an schlechten Metadaten. Denken Sie daran, dass Sie für jede wahrgenommene Langsamkeit verantwortlich gemacht werden, unabhängig von der eigentlichen Ursache. Schlechte Metadaten sind manchmal eine falsche Einschränkung, aber häufiger ist es das Fehlen einer Einschränkung, die die Berücksichtigung einer viel älteren, unerwünschten Option ermöglicht. Conda hat sich in letzter Zeit massiv verbessert, indem es eine kleine Sache gemacht hat: das Entfernen unserer älteren Sammlung von Software, die unzureichende (meistens zu offene) Einschränkungen hatte. Diese offenen Einschränkungen führten dazu, dass Conda wirklich schlechte Lösungen untersuchte, die viele Downgrades erforderten. Hier dauerte das Lösen buchstäblich Stunden. Downgrades sind sehr, sehr teure Vorgänge, da sie kaskadiert werden können, wobei jeder Schritt weniger eingeschränkt und teurer wird.

Das Problem mit der Mentalität „Garbage in, Garbage out“ ist, dass Sie als Betreuer des Solvers die Tasche in der Hand halten. Wenn Sie nicht sehr gute Heuristiken dafür haben, was Müll ist, sind Sie machtlos. Am Ende sind Sie derjenige, der untersuchen muss, warum der Solver langsam ist, das Problempaket isolieren und dann die Ursache des Problems bitten muss, die Dinge zu beheben. Das ist keine gute Position, vertrau mir. Wir verbringen eine Menge Zeit damit, den Leuten zu erklären, warum Conda ewig dauert oder mit einer Mischung aus Conda-Forge, Bioconda oder anderen Kanälen von Drittanbietern nicht funktioniert. Am Ende müssen wir die Detektivarbeit leisten und diesen Drittanbieterkanälen mitteilen, was sie beheben müssen. Es nervt.

Bei jedem Vergleich mit Conda muss berücksichtigt werden, dass Conda das Problem ganz anders angeht. Conda hat eine riesige Metadatenquelle und löst alles auf einmal, aber pip löst und optimiert rekursiv jedes Ding nach dem anderen (Backtracking nach Bedarf). Das kann Ihnen verschiedene Optimierungspfade bieten.

@wolfv hat kürzlich die Verwendung von libsolv für conda erkundet. Letztendlich war er frustriert, dass er es nicht dazu bringen konnte, die gleichen Antworten wie Conda zu geben. Es lief auf diesen Unterschied zwischen den Ansätzen hinaus. Libsolv ist ein Backtracking-Löser. Es kann als optionales kompiliertes Add-On für Pip dienen, um die Dinge zu beschleunigen, obwohl ich weiß, dass Sie empfindlich darauf reagieren, kompilierten Code nicht direkt mit Pip einzuschließen.

( @pradyunsg hat gerade sein August-Update in seinem Blog gepostet.)

Einige der Fragen und Bedürfnisse, die jetzt angesprochen werden, sind Dinge, die wir jetzt sammeln müssen, wie z. B. Testfälle.

Aber auch: Welchen Zeitplan halten wir für diesen Rollout für realistisch? Dies hängt stark von Pradyuns Gesundheit und Freizeit ab, von der Verfügbarkeit von Code-Reviews durch andere Pip-Betreuer und davon, ob wir einige Zuschüsse erhalten, für die wir uns bewerben, aber ich denke, die Reihenfolge ist ungefähr so:

• Build-Logik-Refaktorierung: in Bearbeitung, irgendwann im Dezember-Februar fertig
• UX-Forschung und -Design, Aufbau von Testinfrastrukturen, Gespräche mit Downstreams und Benutzern über Konfigurations-Flags und Übergangszeitpläne: Dafür brauchen wir Finanzmittel; frühester Start ist voraussichtlich Dezember, dauert 2-3 Monate
• Einführung der in resolvelib/zazo definierten Abstraktionen während des Alpha-Tests: Wird ein paar Monate dauern, also, vorsichtig geschätzt, Mai 2020?
• Übernahme einer besseren Abhängigkeitsauflösung und Durchführung von Betatests: ?

Ist das richtig? Was vermisse ich?

Ich frage, weil ein Teil der Arbeit zum Sammeln von Informationen Dinge sind, die ein Projektmanager und/oder UX-Forscher meiner Meinung nach tun sollte, und weil einige Fortschritte bei https://github.com/pypa/packaging-problems/issues/264 und Andere Probleme könnten bei Bedenken helfen, die hier geäußert wurden.

Schlechte Metadaten sind manchmal eine falsche Einschränkung, aber häufiger ist es das Fehlen einer Einschränkung, die die Berücksichtigung einer viel älteren, unerwünschten Option ermöglicht.

Da die Verwendung uneingeschränkter Abhängigkeiten oder >= some_old_version eher die Regel als die Ausnahme für setup.py / pyproject.toml ist, wird dies ein Problem sein. Es ist mir egal, ob es sich um eine "falsche Einschränkung" handelt oder der Solver andere Entscheidungen treffen muss - dies ist der Status der Metadaten auf PyPI.

Diese offenen Einschränkungen führten dazu, dass Conda wirklich schlechte Lösungen untersuchte, die viele Downgrades erforderten.

Sie sind hier der Experte, aber gibt es dafür nicht pragmatische Lösungen? In den meisten Fällen sind keine Downgrades erforderlich, versuchen Sie es also zuerst. Führen Sie dann für jedes Paket nur ein Downgrade von 1 Version durch. Wenn Sie weiter downgraden müssen, ist dies fast immer die falsche Lösung (kann an schlechten Metadaten oder etwas anderem liegen).

Eigentlich bin ich mir nicht sicher, ob pip _can_ Dinge überhaupt herunterstufen kann. Es hatte zuerst eine zu aggressive „Upgrade Everything“-Strategie, jetzt funktioniert „Upgrade nach Bedarf“ ziemlich gut. Ich habe noch nie gesehen, dass es irgendetwas heruntergestuft hat, und in der Praxis funktioniert es ziemlich gut für den regelmäßigen Gebrauch.

Ein Beispiel für ein Downgrade, mit dem Conda fertig werden muss, Pip jedoch nicht: Benutzer von Anaconda oder Miniconda mit Python 3 beginnen mit Python 3.7. Benutzer müssen manchmal etwas installieren, das nur für Python 3.6 verfügbar ist. Der Solver muss Python und alle anderen Nicht-Noarch-Pakete herabstufen. Dies ist ein Sonderfall, der möglicherweise durch ein spezielles Verhalten für Python-Versionsänderungen optimiert werden könnte, aber es veranschaulicht den Punkt, an dem Änderungen in einem Paket Downgrades auf ein anderes erfordern können. "Es hat bisher funktioniert" ist dummes Glück, nicht das, was eigentlich immer funktioniert.

Das Einschränken von Versionen kann nicht in der Lösung selbst angewendet werden. Sie haben Ihre Einschränkungen, und jede Art von "Öffnen durch eine Version" kann nicht allgemein genug sein, da es für jedes Paket anders ist. Sie können Metadaten jedoch vor dem Solver nach Version ausschneiden. Das ist „current_repodata.json“ von Conda. Nur die neuste Version. Es macht die Dinge sehr schnell, wenn es funktioniert, aber die Leute würden wirklich sauer werden, wenn das die einzigen Repodaten wären. Die Dinge wären nicht reproduzierbar, und sie wären frustriert darüber, dass Spezifikationen, die an einem Tag funktionieren, am nächsten möglicherweise nicht mehr funktionieren. Wir bieten einen Rückgriff auf die vollständigen Repodaten und planen auch die Einführung zeitbasierter Teilmengen, wobei nur die neuesten Versionen zu bestimmten Zeitpunkten verfügbar sind. Das inkrementelle Öffnen der verfügbaren Indexdaten könnte ein nützlicheres Konzept mit dem Backtracking-Solver sein.

pip _kann_ Dinge sogar herunterstufen.

Es kann -- für pip ist ein Downgrade nur ein Deinstallations- und Installationsschritt wie ein Upgrade. Und es wird heruntergestuft, wenn es eine Einschränkung sieht, die es erfüllen soll.

Das Folgende führt ein Downgrade von Setuptools durch - solange es das erste ist, was pip sieht:

pip install "setuptools < 20.0"

wo ist der beste Ort, um „Hier ist ein Grenzfall, an den ich gedacht habe“-Szenarien zu posten, damit sie nicht verloren gehen?

https://github.com/pradyunsg/zazo/

Danke, das werde ich mir merken. Wenn ich es mir noch einmal überlege, ist mein „pathologischer Fall“ eigentlich gar nicht so pathologisch. Es ist meistens nur ein extremer Fall der Tatsache, dass Sie das Paket herunterladen und entpacken müssen, um die Abhängigkeitsmetadaten für ein Paket zu kennen, und in bestimmten Fällen kann dies dazu führen, dass viele Pakete heruntergeladen werden, nur um sie abzulehnen. Das könnte eine wichtige Einschränkung des "einfachen Index"-Protokolls sein, die wir ansprechen müssen, aber es ist nicht direkt ein Resolver-Problem.

Ein Beispiel für ein Downgrade, mit dem Conda fertig werden muss, Pip jedoch nicht: Benutzer von Anaconda oder Miniconda mit Python 3 beginnen mit Python 3.7. Benutzer müssen manchmal etwas installieren, das nur für Python 3.6 verfügbar ist. Der Solver muss Python und alle anderen Nicht-Noarch-Pakete herabstufen. Dies ist ein Sonderfall, der möglicherweise durch ein spezielles Verhalten für Python-Versionsänderungen optimiert werden könnte, aber es veranschaulicht den Punkt, an dem Änderungen in einem Paket Downgrades auf ein anderes erfordern können. "Es hat bisher funktioniert" ist dummes Glück, nicht das, was eigentlich immer funktioniert.

Es ist auch ein Fall, in dem Sie normalerweise _kein Downgrade_ durchführen möchten. Als Benutzer würde ich lieber eine Ausnahme erhalten, die mir mitteilt, dass das Paket nicht verfügbar ist, und mich explizit 3.6 installieren lassen, wenn ich das möchte.

Ein weiteres Beispiel ist die Inkonsistenz zwischen Kanälen. Aktuelles Beispiel: Wir waren bei Python 3.7.3, dann bekam base 3.7.4 . Ich interessiere mich nicht für diese Versionsunterschiede, und die meisten Benutzer werden es auch nicht. Ein standardmäßiges "Nichts tun" wäre viel besser als "Hey .4 > .3 , lass uns das aktualisieren und dann die Kanäle anderer Pakete auf base ändern, wenn wir müssen (auch wenn das diese herunterstuft)".

Wir bieten einen Rückgriff auf die vollständigen Repodaten und planen auch die Einführung zeitbasierter Teilmengen, wobei nur die neuesten Versionen zu bestimmten Zeitpunkten verfügbar sind

Das klingt nach einer sehr nützlichen Verbesserung.

Das Problem mit der Mentalität „Garbage in, Garbage out“ ist, dass Sie als Betreuer des Solvers die Tasche in der Hand halten. Wenn Sie nicht sehr gute Heuristiken dafür haben, was Müll ist, sind Sie machtlos.

Ja, das ist wahr. Ich denke, jede IDE, Distribution oder "gemeinsame Schnittstelle zu einem Haufen Sachen" hat dieses Problem.

Das Folgende führt ein Downgrade setuptools

Das ist ein vom Benutzer angefordertes Downgrade. Eine indirekte ist das, was ich meinte (zB setuptools<20.0 in pyproject.toml`). Das würde auch funktionieren, denke ich, aber es ist selten in der Praxis.

Das Problem mit der Mentalität „Garbage in, Garbage out“ ist, dass Sie als Betreuer des Solvers die Tasche in der Hand halten.

100% einverstanden. Es ist etwas, das sehr sorgfältig gehandhabt werden muss. Aber umgekehrt ist der Versuch, ein vernünftiges Verhalten für irgendeinen alten Müll auszuarbeiten, nicht machbar - wir müssen irgendwo eine Grenze ziehen.

Nur zur Erinnerung, diese Diskussion wurde durch die Frage ausgelöst, ob wir den bestehenden Resolver auf unbestimmte Zeit beibehalten müssten. Ich bin mir nicht sicher, ob einer dieser Punkte diese Frage wirklich beeinflusst - der vorhandene Resolver ist nicht richtig, das Beste, was Sie sagen können, ist, dass es ein kaputtes Verhalten ist, mit dem die Leute vertraut sind. Ich bleibe also bei dem, was ich oben gesagt habe, es gibt keinen Grund, den alten Resolver über eine anfängliche Übergangszeit hinaus beizubehalten.

Und tatsächlich werden die alten und neuen Resolver für einen großen Teil der Anwendungsfälle wahrscheinlich sowieso die gleichen Ergebnisse liefern.

"Richtig" spielt für Benutzer keine Rolle, wenn sie durch Ihre Änderungen beschädigt werden. Jede Verhaltensänderung wird einige Benutzer absolut wütend machen. Ihnen zu sagen, dass ihr Arbeitsablauf falsch ist und sie sich ändern müssen, war für mich keine besonders effektive Strategie. Ich denke, man muss es nach Gehör spielen. Ich würde den alten Resolver sicherlich nicht für immer beibehalten wollen, aber Sie müssen den Leuten wahrscheinlich einen Weg geben, ihn zu behalten - wie es zu einem Plugin zu machen, das jemand anderes übernimmt und pflegt, und die Leute können das separat von pip installieren.

Der Versuch, ein vernünftiges Verhalten für irgendeinen alten Müll auszuarbeiten, ist nicht praktikabel - wir müssen irgendwo eine Grenze ziehen.

Ja, aber was ist "alter Schrott"? Was zeichnet es aus? Was ist mit schlechtem oder gutem Müll (wobei zu beachten ist, dass neuer nicht immer besser ist)? Mein Rat ist, viel Zeit damit zu verbringen, den Solver sehr debugfähig zu machen. Machen Sie es Benutzern (nicht nur Ihnen als Experten) leicht, nachzuvollziehen, wo die Dinge seitwärts laufen, damit Sie leicht erkennen können, wann schlechte Metadaten das Problem sind und was diese schlechten Metadaten sind. Dies ist eine Fähigkeit, die die meisten Benutzer derzeit nicht haben, und ehrlich gesagt wollen die meisten Benutzer, die ich gesehen habe, diese Fähigkeit nicht haben. Ich glaube nicht, dass Sie (oder Conda für diese Angelegenheit) jemals in der Lage sein werden, eine vollständig genaue automatische Heuristik für schlecht und gut zu haben.

Es ist auch ein Fall, in dem Sie normalerweise kein Downgrade wünschen. Als Benutzer würde ich lieber eine Ausnahme erhalten, die mir mitteilt, dass das Paket nicht verfügbar ist, und mich explizit 3.6 installieren lassen, wenn ich das möchte.

@rgommers , conda 4.7 wurde dorthin verschoben - erfordert die explizite Python-Spezifikation, um Nebenversionen zu ändern. Die Leute haben es gehasst. Ich habe keine Ahnung, welcher Anteil der Bevölkerung die Vocals sind, aber viele Leute mögen es wirklich, wirklich nicht, dass sie früher etwas conda install konnten, und jetzt können sie es nicht mehr. Sie kümmern sich nicht viel um den Grund und sind größtenteils durch die Antwort besänftigt, aber wir müssen uns in der Zwischenzeit immer noch mit der Feindseligkeit auseinandersetzen. Nur ein weiteres Beispiel für

"Richtig" spielt für Benutzer keine Rolle, wenn sie durch Ihre Änderungen beschädigt werden.

Ein weiteres Beispiel ist die Inkonsistenz zwischen Kanälen. Aktuelles Beispiel: Wir waren bei Python 3.7.3, dann bekam Base 3.7.4. Ich interessiere mich nicht für diese Versionsunterschiede, und die meisten Benutzer werden es auch nicht. Ein standardmäßiges "Nichts tun" wäre viel besser als "Hey .4 > .3, lass uns das aktualisieren und dann die Kanäle anderer Pakete auf Basis ändern, wenn wir müssen (auch wenn das diese herunterstuft)".

Dies ist ein viel komplizierterer Punkt. Sie schlagen im Grunde verschiedene Optimierungskriterien vor. Vielleicht haben Sie die aktuellen 11 Schritte in unserem Blogbeitrag unter https://www.anaconda.com/understanding-and-improving-condas-performance/ gesehen.

Diese sind äußerst knifflig, und es gibt kein globales Optimum, das alle Situationen erfüllt. Angesichts der Binärkompatibilität und der Kanäle als Inseln dieser Kompatibilität ist die starke Priorität der Kanäle ziemlich wichtig. Python-Builds spielen keine Rolle, Sie haben Recht, aber es gibt derzeit keine Möglichkeit, eine binäre Kompatibilitätseinschränkung im Vergleich zu einer einfachen und einfachen Versionseinschränkung auszudrücken. Das bräuchten Sie, um über Ihre Idee nachzudenken, die Dinge einfach in Ruhe zu lassen. Andernfalls wären Sie schnell in der Hölle der binären Inkompatibilität.

Hallo, danke @msarahan , dass du mich in dieser Ausgabe erwähnt hast. Ich wollte mich schon früher melden, habe aber keine Zeit gefunden.

In der Tat habe ich ziemlich viel damit experimentiert, libsolv als Solver für Conda-Spezifikationen zu verwenden. Und es funktioniert -- der verbleibende Unterschied ist jetzt, dass conda sich nicht viel um die Build-Nummer kümmert, aber libsolv in der Art und Weise, wie es codiert ist (und mit dem Backtracking-Solver). Selbst wenn die vollständigen Repodaten verwendet werden, ist libsolv wirklich schnell – ich würde sogar so weit gehen zu sagen, dass die Geschwindigkeit von libsolv schnell genug ist, um nicht nervig zu sein :)

Mein großer Beitrag zu libsolv bestand darin, es plattformübergreifend kompatibel zu machen, sodass es jetzt unter Windows, OS X und Linux kompiliert werden kann.

Ich würde absolut dafür plädieren, libsolv für einen neuen Resolver zu verwenden, auch wenn es sich um einen Haufen kompilierten Codes handelt (zumindest ist er schnell) und @mlschroe könnte verfügbar sein, um zu helfen – er hat viel mit der libsolv-Unterstützung für geholfen die conda matchspez.

Andererseits bin ich mir nicht sicher, in welchem ​​Stadium sich die Resolver-Entwicklung befindet und ob es jetzt schon zu spät ist und ob kompilierter Code akzeptabel ist oder nicht.

Vielleicht haben Sie die aktuellen 11 Schritte in unserem Blogbeitrag unter https://www.anaconda.com/understanding-and-improving-condas-performance/ gesehen.

Das habe ich tatsächlich. Das war ein schöner Blogbeitrag.

Sie schlagen im Grunde verschiedene Optimierungskriterien vor.

nicht wirklich. Ich denke, Ihre _"Einschränkung der binären Kompatibilität im Vergleich zu einer einfachen und einfachen Versionseinschränkung"_ weist nur auf etwas hin, das ich wahrscheinlich übersehe. Was ich erwarten würde, ist, dass kein Paket python >= 3.7.4 oder == 3.7.4 in seinen Metadaten haben sollte, es ist immer == 3.7 (nur auf scipy geprüft, meta.yaml sagt python und conda_forge.yml sagt max_py_ver: '37' - macht Sinn). Die Einführung von 3.7.4 sollte also nichts bewirken - der Resolver, der 3.7.3 wählt und nichts anderes ändert, ist viel billiger (und gemäß Ihren 11 Schritten gültig), als 3.7.4 zu erzwingen und a auszulösen Kette von Auf- und Abstiegen.

Ich schätze, dieser Teil wird für pip -Rollout-Pläne vom Thema abgekommen, also nehme ich das gerne woanders hin.

Mein Rat ist, viel Zeit damit zu verbringen, den Solver sehr debugfähig zu machen.

+1

Außerdem: Machen (halten) Sie es so reparierbar wie möglich. Das ist jetzt das Schöne an pip , wenn es schief geht, kann man normalerweise cd site-packages && rm -rf troublesome_package machen (evtl. gefolgt von einer Neuinstallation mit --no-deps ) und die Dinge funktionieren wieder. Dinge wie conda , apt und Co. sind auf diese Weise viel schwerer zu reparieren.

Sie schlagen im Grunde verschiedene Optimierungskriterien vor.

Ich glaube nicht, dass Sie das Konzept der Kanäle in Ihrem Denken genug berücksichtigen. Ich weiß nicht, wie relevant es ist, Pip zu machen. Auf jeden Fall viel weniger als für Conda, aber ich bin mir nicht sicher, ob es völlig irrelevant ist. Leute können immer noch Pakete von mehr als einem Index gleichzeitig sammeln, richtig?

Pakete haben weder Python >=3.7.4 noch ==3.7.4. Der Standard bei Conda-Verpackungen besteht darin, eine Ober- und Untergrenze zu haben. Diese werden im Allgemeinen automatisch von conda-build unter Verwendung von Informationen bestimmt, die vom Autor des Rezepts bereitgestellt werden, in Bezug darauf, wie viele Stellen der Version als kompatibler Bereich betrachtet werden sollen. Pakete haben Einschränkungen wie >=3.7.2,<3.8.0a0, wobei die Unbeholfenheit von 0a0 dafür verantwortlich ist, dass Vorabversionen unter .0-Releases liegen und daher einer <3.8.0-Spezifikation entsprechen würden, wo dies nicht der Fall ist erwarte es wirklich.

Paketen ist auch ein Kanal zugeordnet. Dieser Kanal ist quasi Teil der Versionsoptimierung: https://github.com/conda/conda/blob/4.6.7/conda/resolve.py#L1074 - der Kanal ist wie eine Super-Version, der einen Platz voraus Hauptversion des Pakets. Wenn eine Lösung Python nicht ändern soll, kann die Python-Spezifikation nicht python ==3.7 sein - das ist ein Bereich, und der Kanal wirkt sich auf diesen Bereich aus. Insbesondere wenn Sie eine python ==3.7-Spezifikation haben und mit einer Installation aus dem defaults -Kanal beginnen und dann den conda-forge -Kanal hinzufügen, führt dies zu einer großen Abwanderung, da Sie neue Python-Pakete eingeführt haben sind höher in "Version" (einschließlich Kanal), und Ihre Python-Spezifikation lässt diese Änderung zu.

Conda 4.7 führte ein viel aggressiveres "Einfrieren" von Spezifikationen ein, und ich bin mir ziemlich sicher, dass Sie dieses Verhalten suchen. Das ist allerdings ziemlich kompliziert. Es läuft darauf hinaus, nur Dinge einzufrieren, die nicht mit Ihren expliziten Spezifikationen in Konflikt stehen. Wie Sie "Konflikt" bestimmen, ist der schwierige Teil. Wir denken, dass es besser ist, Dinge nicht einzufrieren, die den Solver daran hindern würden, dem Benutzer die neuesten Pakete zu geben, die Teil des Diagramms der Abhängigkeiten für dieses Paket sind. Dieses Einfrieren ist erwähnenswert, da es für pip auf einer pro-Spezifikationsbasis auf eine Weise durchgeführt werden kann, die conda nicht kann. Ich denke, es könnte eine großartige Optimierung für einen Backtracking-Löser sein.

Außerdem: Machen (halten) Sie es so reparierbar wie möglich. Das ist jetzt das Schöne an Pip, wenn es schief geht, kann man normalerweise cd site-packages && rm -rf Troublesome_package machen (möglicherweise gefolgt von einer Neuinstallation mit --no-deps) und die Dinge funktionieren wieder. Geräte wie Conda, Apt und Co. sind auf diese Weise viel schwerer zu reparieren.

Ja, das ist sehr wichtig. Ich denke, pip hat gute Arbeit geleistet, Dinge vernünftig zu verkaufen, damit es schwieriger ist, sie zu brechen. Das ist sehr weise, und conda lernt daraus. Wenn Sie am Ende kompilierten Code verwenden, stellen Sie sicher, dass er statisch gelinkt ist oder dass das dynamische Laden auf andere Weise keine Probleme verursachen kann.

(Libsolv-Tangente: Damals, als ich für RH arbeitete, habe ich https://pypi.org/project/solv/ aufgerufen, um die Sicherheitslücke "pip install solv" auf Fedora zu schließen, da der libsolv-Build-Prozess keine generiert sdist oder wheel archive im Moment, ganz zu schweigen davon, es auf PyPI zu veröffentlichen. Ich freue mich, mit jedem zu chatten, der daran interessiert sein könnte, diese echten Bibliotheksbindungen mit einer Bundle-Kopie von libsolv zu erstellen, anstatt mit dem harmlosen Platzhalter, der es jetzt ist)

In Bezug auf meinen Kommentar zum „Ablehnen“ meine ich nicht „auf die alte Installationslogik zurückgreifen“, sondern „eine Option bereitstellen, um die Installation von Paketen zu überspringen, die zu Einschränkungen führen würden, anstatt die gesamte Installationsanforderung fehlschlagen zu lassen“.

Yum/DNF bieten dies über ihre Option --skip-broken an (in DNF ist dieses Flag ein Alias ​​für --setopt=strict=0 ), und ich denke, der Resolver pip sollte eine ähnliche Option bieten.

@ncoghlan Ah richtig. Das macht Sinn.

Stiloption "Versionskonflikte in diesem Paket ignorieren".

Ich hatte bereits erwähnt, dass wir das tun würden, weshalb mich Ihr Kommentar verwirrt hat.

Da sind wir auf der gleichen Seite. :)

@ncoghlan antwortete auf meine vorgeschlagene Zeitleiste auf distutils-sig und sagte, es klinge vernünftig.

@pradyunsg - wir freuen uns auf Ihr nächstes monatliches Update!

Ich verbrachte einige Zeit damit, mir das noch einmal anzusehen, und reichte #7317 ein.

Ich denke, wir haben es fast geschafft, was die Abstraktionen angeht – dank viel Arbeit an der Indexinteraktion von pip, Abhängigkeitsauflösung + Build-Logik-Trennung und einer Reihe allgemeiner Aufräumarbeiten.

Ich habe gerade #7317 geschlossen. Soweit ich das beurteilen kann, ist die Abhängigkeitsauflösung jetzt (ausreichend) von der Metadaten-Erstellungslogik entkoppelt. Der Build-Logik-Refaktor hat sich gut entwickelt und ist jetzt kein Hindernis mehr für weitere Fortschritte.

Wir können jetzt mit der Arbeit an der Implementierung der [resolvelib]-Abstraktionen in pip beginnen, wobei wir gegebenenfalls auf [passa] und den Resolver der Poesie verweisen. :)

@pradyunsg Ich plane, den Basis-Resolver (basierend auf PubGrub) aus der Poetry-Codebasis zu extrahieren (siehe https://github.com/sdispater/poetry/tree/master/poetry/mixology). Es ist größtenteils vom Rest des Codes entkoppelt, aber es gibt immer noch Verweise auf interne Teile, die ich abstrahieren muss.

Wenn Sie daran interessiert sind, dabei zu helfen, lassen Sie es mich bitte wissen. Die Idee ist, eine eigenständige Implementierung des PubGrub-Algorithmus zu haben, die von Dritten verwendet werden kann und in https://pypi.org/project/mixology/ eingefügt wird, das derzeit den Code des alten Resolvers enthält.

@sdispater Auf jeden Fall! Ich weiß nicht, ob ich direkt helfen kann (Zeitdruck), aber es wäre großartig, wenn Sie den PubGrub-Port vom Rest der Poesie entkoppeln könnten!

Eines der Dinge, die wirklich schön wären, wäre eine konsistente Abstraktionsschicht, so dass Pip, Poesie und Pipenv dieselben Abstraktionen verwenden. Im Moment haben wir Zazo (meins), Mixology (Poesie) und Resolvelib (Pipenvs) – alle definieren eine Art Abstraktionsebene und sie sind leicht unterschiedlich, aber (lächerlicherweise!) ähnlich. Wenn Sie dafür offen sind, lassen Sie es uns wissen!

Zu Ihrer Information, wir ( @wolfv und das @QuantStack- Team im Allgemeinen) haben auf die RfP für den Pip-Abhängigkeitsauflöser geantwortet.

Der vorgeschlagene Ansatz besteht darin, die C-Bibliothek libsolv zu übernehmen und die Unterstützung für das Versionseinschränkungsformat von pip zu libsolv beizutragen. Wir würden die C-Bibliothek durch neue Python-Bindungen verfügbar machen.

Libsolv ist eine kampferprobte Bibliothek, die dem RPM-Ökosystem zugrunde liegt und daher bereits im industriellen Maßstab eingesetzt wird.

• Libsolv wird unter der BSD-3-Clause-Lizenz vertrieben.
• Libsolv unterstützt mehrere Pakete und Repository-Formate wie rpm , deb ,
  haiku , conda , arch . Wichtig ist die Vielfalt der Formate und Ausdrucksmöglichkeiten
  Abhängigkeitsbeschränkungen zeigen, dass es sich um ein steckbares System handelt, das dazu in der Lage sein sollte
  um die Syntax von pip für Einschränkungen bei Abhängigkeitsversionen zu berücksichtigen.
• Wir haben libsolv anstelle von Condas Solver im dünnen Mamba-Wrapper verwendet
  in der Lage, die Leistungen von Conda deutlich zu verbessern. (Condas Langsamkeit bei der Paketauflösung mit großen Kanälen war unsere Hauptmotivation für die Arbeit an Mamba).
• Es funktioniert plattformübergreifend unter Windows, OS X und Linux. ( @wolfv hat die Windows-Portierung von libsolv gemacht)
• Es führt eine vollständige SAT-Lösung durch, um optimale Abhängigkeitskombinationen zu finden, und wenn dies nicht gelingt, gibt es umsetzbare Hinweise zur Konfliktlösung zurück.

Der vorgeschlagene Ansatz besteht darin, die libsolv C-Bibliothek zu übernehmen

Es müsste ein Fallback für Plattformen geben, die libsolv nicht unterstützt (z. B. wird aktiv an der AIX-Unterstützung in pip gearbeitet, und Sie haben BSD nicht erwähnt). Daher ist libsolv als Performance-Option, wo verfügbar, für mich plausibel, aber wir sind nicht wirklich in der Lage, sie nur zu verwenden. (Gibt es eine reine Python-Version von libsolve, dh etwas, das die gleichen Ergebnisse liefert, nur langsamer?)

Wie würde get-pip.py funktionieren? Müssen wir Binärdateien für libsolv für alle möglichen Plattformen einschließen? Auch hier würde ich nicht davon ausgehen, dass wir ein reines Python-Fallback verwenden würden.

Dass externer C-Code nicht verwendet werden kann, ist für pip schon lange ein Ärgernis. Ich würde gerne eine gute Lösung dafür sehen, aber (a) ich bin mir nicht sicher, ob es eine gibt (abgesehen von einer Art "Mini-Pip"-Bootstrapper-Lösung, die es uns ermöglicht, insgesamt zu de-vendoren) und (b) Es ist ein Stück Arbeit, das groß genug ist, dass ich es hassen würde, wenn der neue Resolver darauf angewiesen wäre.

Hallo @pfmoore

Ich denke, zusätzliche Plattformunterstützung sollte nicht so schwer zu erreichen sein, da libsolv ziemlich einfacher C-Code ist. Ich bin mir ziemlich sicher, dass es keine reine Python-Version von libsolv gibt (was ich als Nachteil verstehe, aber es gibt auch keine reine Python-Version von Python oder die Python-Standardbibliothek, also sollte es meiner Meinung nach keine sein Sperrer).

Ich denke, zum Bootstrapping könnte man einen reinen Python-Pip haben, der den aktuellen Mechanismus zum Auflösen verwendet, der dann die erforderliche Resolver-Bibliothek basierend auf libsolv installiert. Beispielsweise könnte man das genaue Paket der libsolv + pip-spezifischen Python-Bindungen anheften und sie wie von Ihnen beschrieben vom boostrap-pip installieren. Es klingt für mich absolut machbar, aber Sie wissen vielleicht besser, was dazu gehört ...

Ich denke, zusätzliche Plattformunterstützung sollte nicht so schwer zu erreichen sein

Um es klar zu sagen, ich habe kein begründetes Interesse an den Nischenplattformen, ich denke nur, wir müssen sehr klar sein, ob wir beeinflussen, auf welchen Plattformen Pip unterstützt wird (was im Moment im Grunde "alles ist, was Python ausführen kann"). ). Es gibt auch die Bereitstellungsfrage, wie wir eine C-Erweiterung versenden (da pip derzeit als "universelles" Rad ausgeliefert wird und das für einige Anwendungsfälle wie get-pip.py wichtig ist).

Ich denke, zum Bootstrapping könnte man einen reinen Python-Pip haben, der den aktuellen Mechanismus zum Auflösen verwendet

Ich habe oben argumentiert, und ich werde es hier wiederholen, ich möchte nicht wirklich zwei Resolver in Pip auf unbestimmte Zeit unterhalten müssen.

Aber ich möchte den Vorschlag nicht zu negativ bewerten – ich wollte nur einige der Gründe hervorheben, aus denen wir derzeit keine Abhängigkeiten von C-Erweiterungen zulassen, falls Sie sich dessen nicht bewusst waren.

Die Diskussion ist wahrscheinlich anderswo besser geeignet und könnte völlig überflüssig sein, wenn/falls mehr Details enthüllt werden, aber ich möchte jetzt wirklich meine Fragen herauslassen.

Nach meinem Verständnis verwendet libsolv einen vollständigen SAT-Solver für die Auflösung von Abhängigkeiten und erfordert das Laden von Abhängigkeitsinformationen, bevor es mit dem Lösen beginnt. Aber PyPI speichert ab sofort Abhängigkeitsmetadaten pro Paket. Selbst wenn Sie die laufzeitabhängige Natur von setup.py ignorieren, wäre es schwierig, die für den SAT-Solver erforderlichen Informationen effizient abzurufen.

Wie wollen Sie mit diesem Problem umgehen? Planen Sie die Implementierung einer Infrastruktur (und schlagen zusätzliche Spezifikationen für Repo-Implementierungen von Drittanbietern vor), um .solv -Dateien zu generieren, wenn Pakete hochgeladen werden? Oder haben Sie einige Strategien im Ärmel, um geeignete lösbare Daten zu generieren, während der Solver fortschreitet, und vielleicht ein Backtracking zu implementieren, wenn neue Abhängigkeitsdaten eingehen?

Mir ist keine diesbezügliche Arbeit bekannt, und die meisten Ressourcen, die ich finden kann, deuten darauf hin, dass die Python-Paketierungslandschaft etwas anderes / mehr als einen direkten SAT-Löser benötigt. Daher bin ich an allen Möglichkeiten hier sehr interessiert.

Diese .solv-Dateien dienen nur zum Caching, libsolv benötigt sie nicht zum Lösen. Aber ich stimme zu, dass die dynamische Natur der Abhängigkeiten von PyPI es schwierig macht, einen SAT-Solver zu verwenden.

(Weitere Informationen finden Sie unter https://docs.google.com/document/d/1x_VrNtXCup75qA3glDd2fQOB2TakldwjKZ6pXaAjAfg/edit)

(Beachten Sie, dass ein SAT-Solver nur ein Backtracking-Solver ist, der auch Klauseln lernt, wenn es zu einem Konflikt kommt, daher denke ich, dass es möglich ist, einen SAT-Solver für PyPI zu verwenden. Aber es muss ein Solver sein, der es ermöglicht, Klauseln dynamisch hinzuzufügen beim Lösen.)

Sat-Solver verfügen heutzutage über einige bedeutende Fähigkeiten, darunter dynamische Hinzufügungen, Neustarts, Backtracking, zufällige Neustarts usw. Aber ich denke, die Herausforderungen hier werden teilweise technischer Natur sein und mit der Notwendigkeit zusammenhängen, Plattformen zu unterstützen, für die es keine Garantie gibt, dass Sie bauen können ein C-basierter Solver.

Ich bin gerade am Flughafen, also kann ich nicht auf die Punkte antworten, die jetzt angesprochen wurden, aber ... Ich bin sicher, wir sollten hier nicht die technischen Entscheidungen/Kompromisse diskutieren - das ist eher darauf ausgerichtet wie wir die Einführung kommunizieren und verwalten im Vergleich zu dem, was wir einführen. :)

Ich habe #7406 für weitere Diskussionen über die technischen Kompromisse eingereicht – @sdispater , @techalchemy , @uranusjr , @wolfv Ich würde es begrüßen, wenn wir die weitere Diskussion über die verschiedenen Möglichkeiten für das Resolver-Design führen könnten.

Um die Erwartungen frühzeitig festzulegen, werde ich für die nächsten 2 Wochen reisen und hoffentlich in der Lage sein, die ganze Diskussion am ~9. Dezember nachzuholen.

Statusaktualisierung: Die PSF konnte vom Mozilla Open Source Support und der Chan-Zuckerberg-Initiative etwas Geld erhalten, um Auftragnehmer einzustellen, die am Pip-Resolver und damit verbundenen Problemen mit der Benutzererfahrung arbeiten . Sie können unsere Roadmap (die ich aufpolieren muss) und Blog- und Forum- und Mailinglistenbeiträge sowie Notizen von den letzten Meetings sehen, um auf dem Laufenden zu bleiben. Ich werde bald etwas darüber in distutils-sig und im Packaging-Forum auf Pythons Discourse-Instanz posten.

Unser Ziel ist es, die Resolver-Funktion von pip für die Veröffentlichung in pip 20.2 im Juli vorzubereiten. (Gemäß der vierteljährlichen Veröffentlichungskadenz für Pip können sich unvorhergesehene Schwierigkeiten bis zum 20.3. im nächsten Quartal verzögern.)

@uranusjr :

Nach meinem Verständnis verwendet libsolv einen vollständigen SAT-Solver für die Auflösung von Abhängigkeiten und erfordert das Laden von Abhängigkeitsinformationen, bevor es mit dem Lösen beginnt. Aber PyPI speichert ab sofort Abhängigkeitsmetadaten pro Paket. Selbst wenn Sie die Laufzeitabhängigkeit von setup.py ignorieren, wäre es schwierig, die für den SAT-Solver erforderlichen Informationen effizient abzurufen.

Der Prototyp des pip resolve -Befehls in #7819 verwendet zwei Techniken, um diese Informationen performant zu erhalten (siehe diese Ausgabe für Details):

1. > Extrahieren des Inhalts der METADATA-Datei aus einer URL für ein Rad, ohne das Rad tatsächlich herunterzuladen.
2. > Zwischenspeichern des Ergebnisses jedes Aufrufs von self._resolve_one() in einer persistenten JSON-Datei.

Die für (1) verwendete Technik ist in der Lage, eine Rad-URL sehr schnell in eine Liste von Anforderungszeichenfolgen umzuwandeln, von denen sie abhängt, während nur wenige KB des Inhalts des Rads selbst heruntergeladen werden. Der Prototyp in #7819 stellt dann sicher, dass req.populate_link() für jede der abhängigen Anforderungen aufgerufen wird, die von self._resolve_one() zurückgegeben werden, und speichert die Zuordnung von (==Requirement, url) -> [list of (==Requirement, url) non-transitive dependencies] in einer persistenten JSON-Cache-Datei. (1) erhält schnell neue Informationen, (2) macht alte Informationen schnell abrufbar.

Obwohl ich mit libsolv noch nicht vertraut bin, glaube ich, dass Einträge dieser Zuordnung von Anforderungs-URL zu Abhängigkeiten und ihren URLs genau die atomare Eingabe sein können, die von einem SAT-Solver benötigt wird. Wie in #7189 demonstriert, führte die persistente json-Abhängigkeits-Cache-Datei dazu, dass pip resolve -Aufrufe nach der ersten Ausführung zu vollständigen No-Ops wurden, was von da an 800–900 ms auf der Befehlszeile dauerte. Wenn die Techniken aus (1) und (2) verwendet werden, glaube ich, dass es möglich sein kann, einen SAT-Löser jedes Mal, wenn pip aufgerufen wird, bis zum Ende laufen zu lassen, ohne unglaublich lange warten zu müssen. Es wäre wahrscheinlich nicht allzu schwierig, zu versuchen, libsolv zusätzlich zum Prototyp in #7189 zu hacken, um diese Zahl konkreter zu machen.

@techalchemie :

Sat-Solver verfügen heutzutage über einige bedeutende Fähigkeiten, darunter dynamische Hinzufügungen, Neustarts, Backtracking, zufällige Neustarts usw. Aber ich denke, die Herausforderungen hier werden teilweise technischer Natur sein und mit der Notwendigkeit zusammenhängen, Plattformen zu unterstützen, für die es keine Garantie gibt, dass Sie bauen können ein C-basierter Solver.

pants hatte früher Code, der es einfacher machte, einen Compiler und Linker für ein setup.py -basiertes Projekt verfügbar zu machen (#6273), aber wir haben diesen später entfernt (siehe #7016), um das Erstellen zu ermöglichen C/C++ in Hosen ohne Verwendung setup.py , was für unseren Anwendungsfall innerhalb von Twitter angemessen war, wo nur eine gemeinsam genutzte Bibliothek für benutzerdefinierte TensorFlow-Operatoren erstellt werden musste. Wir hosten vorgefertigte Binärdateien für statisch gelinkte GCC- und Binutils-Archive auf unserem s3 für OSX und Linux (siehe https://github.com/pantsbuild/binaries/), sodass Pants-Benutzer außer Python und einem JDK nichts installieren müssen Hosen überhaupt zu benutzen.

Ich wäre daran interessiert, beim Brainstorming und/oder der Entwicklung von Werkzeugen zum portierbaren Erstellen von C und C++ zu helfen, mit denen pip auf allen unterstützten Plattformen zuverlässig von libsolv abhängig sein kann.

@cosmicexplorer

pants hatte früher etwas Code, der es einfacher machte, einen Compiler und Linker für ein setup.py-basiertes Projekt verfügbar zu machen (#6273), aber wir haben diesen später entfernt (siehe #7016), um das Erstellen von C/C++ zu ermöglichen in Hosen ohne die Verwendung von setup.py, was für unseren Anwendungsfall innerhalb von Twitter geeignet war, das nur eine gemeinsam genutzte Bibliothek für benutzerdefinierte TensorFlow-Operatoren erstellen musste. Wir hosten vorgefertigte Binärdateien für statisch gelinkte GCC- und Binutils-Archive auf unserem s3 für OSX und Linux (siehe pantsbuild/binaries), sodass Pants-Benutzer nichts außer Python und einem JDK installieren müssen, um Pants überhaupt zu verwenden.

Die Compiler/Linker-Arbeit ist sehr interessant! Es gibt auch Diskussionen über die Entkopplung des Compilers von setup.py (oder einem PEP 517-Build-Backend im Allgemeinen). Es hat nicht wirklich mit dem Resolver zu tun (zumindest nicht direkt), aber Sie könnten interessiert sein: https://discuss.python.org/t/how-do-we-get-out-of-the-business-of- fahren-c-compiler/2591

@cosmicexplorer

Ich wäre daran interessiert, beim Brainstorming und/oder der Entwicklung von Werkzeugen zum portierbaren Erstellen von C und C++ zu helfen, mit denen pip auf allen unterstützten Plattformen zuverlässig von libsolv abhängig sein kann.

Ich selbst und @wolfv haben uns dies angesehen, um Teile des DNF-Paketmanager-Stacks auf allen wichtigen unterstützten Plattformen für Mamba und meine eigene persönliche Arbeit mit DNF zu erstellen. Zu diesem Zeitpunkt kann libsolv jetzt für Windows, Linux, macOS, BSD, Haiku OS erstellt werden, und mir ist vage bewusst, dass es im Rahmen der Verwendung von DNF unter UNIX auf verschiedenen UNIX-Systemen installiert wird. Ich weiß, dass @dralley auch solv Binärräder für ~große Plattformen verfügbar gemacht hat, die von PyPI unterstützt werden~ Linux mit manylinux2014 auf PyPI .

Wir haben jetzt pip 20.1b1 herausgebracht, eine Betaversion, die eine sehr frühe (Alpha-)Version des neuen Resolvers enthält (siehe #8099 für den Kontext dazu und eine Umfrage, bei der Leute Feedback geben können). Hier ist die Ankündigung . Und https://github.com/pypa/pip/issues/7951#issuecomment -617851381 listet einige Orte auf, an denen wir die Beta bisher veröffentlicht haben.

Pip 20.1 ist jetzt verfügbar und enthält die Alpha-Version des Resolvers.

Wir diskutieren über die Veröffentlichung einer weiteren Pip-Veröffentlichung im Mai, eine, die eine weiterführende Alphaversion des Resolvers enthält. Und wir finden heraus, wann wir die Beta des neuen Resolvers veröffentlichen und einen „Bitte testen“-Push machen.

Wir sind in Verzögerungen geraten, als wir #8371 herausgefunden haben, wie wir bestimmte Fehlermeldungen besser anzeigen können, und eine Menge anderer haariger Dinge handhaben; Weitere Informationen zu unseren Fortschritten finden Sie unter https://github.com/pypa/pip/projects/6 und https://github.com/pypa/pip/projects/5 . #8206 ist eine Diskussion über die kommende Beta, Pip 20.2b2, die wir hoffentlich bis Ende Juni veröffentlichen können.

Ich habe unseren Halbjahresbericht im PSF-Blog veröffentlicht . Eine wichtige Sache, die Sie wissen sollten: Später in diesem Monat werden wir Pip 20.2 veröffentlichen , das eine Beta-Version des neuen Dependency-Resolvers (Pip 20.1 hatte eine Alpha-Version) über ein optionales Flag „ --use-feature=2020-resolver “ verfügbar sein wird. Wir werden pip 20.2 viel publizieren und viele Benutzer bitten, den neuen Resolver auf Herz und Nieren zu testen.

Per #8511 haben wir jetzt pip 20.2 veröffentlicht. Diese Version enthält die Betaversion des Abhängigkeitsauflösers der nächsten Generation . Es ist wesentlich strenger und konsistenter, wenn es inkompatible Anweisungen erhält, und reduziert die Unterstützung für bestimmte Arten von Einschränkungsdateien, sodass einige Problemumgehungen und Arbeitsabläufe möglicherweise unterbrochen werden. Bitte testen Sie es mit dem Flag --use-feature=2020-resolver . Weitere Informationen zum Testen und Migrieren sowie zum Melden von Problemen finden Sie in unserem Leitfaden . Der neue Abhängigkeitsauflöser ist standardmäßig deaktiviert, da er noch nicht für den täglichen Gebrauch bereit ist .

Wir planen, die nächste vierteljährliche Version von pip, 20.3, im Oktober 2020 herauszubringen. Wir bereiten uns darauf vor, das standardmäßige Abhängigkeitsauflösungsverhalten zu ändern und den neuen Resolver zum Standard in pip 20.3 zu machen.

Bitte verbreiten Sie die Nachricht, indem Sie auf diesen Blogbeitrag verweisen – verbreiten Sie die Nachricht auf Hacker News, Reddit, Twitter, Facebook, Dev.to, Telegram, relevanten Stack Overflow-Antworten und Ihren bevorzugten Slacks und Discords. Die meisten Menschen, die davon betroffen sind, halten sich nicht mit Python-spezifischen Entwicklernachrichten auf dem Laufenden. Helfen Sie ihnen, sich vor Oktober zu informieren, und helfen Sie uns, ihre Fehlerberichte zu erhalten.

(Ich kopiere meine Notiz von #988.)

@zooba fragte :

Denken Sie, dass wir die mit Python 3.9 gebündelte Version von pip zu diesem Zeitpunkt (für den ersten RC) aktualisieren sollten?

Gibt es in ähnlicher Weise eine Notwendigkeit, Python 3.8 für die nächste Version zu aktualisieren?

Meine Annahme ist, ja, nach dem Bugfix-Release Anfang nächster Woche, ja, aber @pfmoore @xavfernandez @cjerdonek @uranusjr @pradyunsg @dstufft was denkst du?

Entschuldigung, zu früh auf den Beitrag geklickt. Meine Überlegung ist, dass das Bündeln von pip 20.2 es erfahrenen Entwicklern viel einfacher machen wird, den neuen Abhängigkeitsauflöser einfach zu testen, während sie die neuesten Versionen von Python testen. Aber ich weiß nicht, wie viel Arbeit es ist, diese gebündelte Version zu aktualisieren, oder wie oft Sie es tun möchten.

Auch hier wäre es schön, 20.2.x in 3.9 aufzunehmen, um den Zugriff auf den neuen Resolver zu erleichtern.

was denkst du?

Du hast Recht, das ist der Plan. :)

OK, auf python-dev beantwortet – ja, die Version von pip, die in Python 3.8 und 3.9 gebündelt ist, sollte auf 20.2.x aktualisiert werden.

Unabhängig davon werde ich in Bezug auf die Öffentlichkeit hier auf einige laufende Arbeiten hinweisen:

In den nächsten 6-8 Wochen werde ich darauf drängen, eine breite Öffentlichkeit zu erreichen, damit die Benutzer versuchen, den neuen Pip zu verwenden. Ich vermute, dass das Problem nicht so sehr darin besteht, dass dieses einzelne Paket nicht installiert werden kann. Es wird unerwartete Konflikte zwischen bestimmten Paketen geben, die möglicherweise von der Umgebung und bestimmten Einschränkungsdateien abhängen. Wir versuchen, über die Umfrage frühzeitig Feedback zu erhalten, damit wir dann Fehler beheben, automatisiertere Tests einrichten usw : das TensorFlow/numpy/scipy-Problem in https://github.com/pypa/pip/issues/8076#issuecomment-666493069 ).

Egal, wie viel Mühe wir darauf verwenden, es wird Benutzer geben, die mit Inkonsistenzen zu tun haben, die mit 20.3 ins Stolpern geraten, und sie werden frustriert, verwirrt und verletzt sein, und das wird eine Supportlast für uns und alle ihre Upstreams verursachen. Wir wollen dies reduzieren, indem wir die Benutzer zum Testen bringen und die Aufmerksamkeit der Upstreams auf uns ziehen.

Daher plane ich, die Gruppen zu kontaktieren und zu nutzen, die auf ihre eigenen speziellen domänenspezifischen Ecken achten – die Datenwissenschaftler, die Lehrer, die Künstler, die DevOps-Spezialisten und so weiter.

Ich gehe davon aus, dass eine Möglichkeit, ihre Aufmerksamkeit zu erregen, über die spezifischen Pakete führt, auf die sie sich verlassen.

Gestern habe ich einige Listen mit weit verbreiteten Paketen durchgesehen und einige Personen manuell per E-Mail kontaktiert und Probleme in einigen Repositories erstellt, um vorzuschlagen, dass sie ihre Benutzer bitten, mit der Beta des neuen Resolvers zu testen, den Stein ins Rollen zu bringen und einige auszuprobieren Formulierungen/Ansätze, um mehr Publicity und Tests zu bekommen. Dies hat in mindestens einem Fall zu Verwirrung geführt – siehe https://github.com/sqlalchemy/mako/issues/322#issuecomment-667546739 – und sobald die Bugfix-Version von 20.2 draußen ist, werde ich ein bisschen mehr sein systematischer und klarer

• warum wir uns melden
• wen wir kontaktieren möchten/wann (die Verknüpfung mit einer öffentlichen Medienstrategie hilft)
• warum wir automatisierte Tests nicht verwenden können, um diese Probleme selbst zu finden

Wir haben ein wenig Aufmerksamkeit auf Twitter ( 1 , 2 ) und Reddit (jemand möchte auf diese Frage zur PyPA-Finanzierung antworten ?) bekommen.

@zooba schrieb (bezüglich der Bündelung):

Danke. Es sieht so aus, als könnten wir es später in dieser Woche tun und die nächste Runde von Veröffentlichungen machen. Bitte teilen Sie uns so schnell wie möglich mit, wenn etwas auftaucht, das Sie nicht veröffentlichen möchten.

Ich finde, dass das --use-feature=2020-resolver für mich im Allgemeinen mehr Probleme behebt, als es verursacht.

ist es zu spät, um einen ersten Rollout vorzuschlagen über:

vorgeschlagener 20.3-Pseudocode

try:
    _2020_resolver()
except:
    legacy_resolver()

was zumindest für meine Projekte bedeuten würde, dass sie alle ohne Änderung bestehen würden

Nachdem der Legacy-Resolver standardmäßig deaktiviert ist, habe ich möglicherweise einige Projekte, die unter dem 2020-Resolver und einige nicht unter dem Legacy-Resolver funktionieren. Ich möchte in der Lage sein, ein Flag zu setzen, um einen Fallback zu aktivieren:

vorgeschlagener 20.4-Pseudocode

try:
    _2020_resolver()
except:
    if not use_legacy_resolver:
        raise
    legacy_resolver()

Wir planen, 20.3 später in diesem Monat einzuführen. Wir gehen davon aus, dass dies eine Menge Benutzerunterstützung erfordern wird, da verwirrte Benutzer uns Fragen stellen.

@di hat sich freiwillig gemeldet, um einige Freiwillige zu sammeln, die bei der ersten Reaktion helfen. Diese Freiwilligen werden Fragen beantworten und bei der Belastung des Benutzersupports helfen, sobald der neue Pip herauskommt – auf Twitter, StackOverflow und GitHub – und echte Fehler an das Betreuer-/Mitwirkende-Team eskalieren.

Dustin, ich denke, Sie haben einen groben Plan, wie das funktionieren würde - würden Sie das hier posten und dann werde ich etwas Konsens von anderen Pip-Betreuern bekommen? Vielen Dank.

Hier mein grober Plan:

• Starten Sie eine Diskussion auf Discussion.python.org und bitten Sie um Unterstützung
• Leiten Sie Leute zu einem Slack-Kanal weiter, der als Kommunikationskanal zwischen allen dienen könnte
• Starten Sie ein Dokument, das einige häufig gestellte Fragen und unsere Antworten beschreibt
• Fügen Sie einen Entscheidungsbaum für neues Problem -> gesichtetes Problem hinzu
• Teile dies mit dem Kanal, sobald wir ein bekanntes Veröffentlichungsdatum haben
• Versuchen Sie, die Freiwilligen grob so einzuplanen, dass sie in den Tagen nach der Veröffentlichung online sind und sie sichten

Danke, @di. Wir warten bis morgen auf OKs von anderen Maintainern. Und wir streben an, Pip 20.3 am Mittwoch oder Donnerstag, den 28. oder 29. Oktober, zu veröffentlichen.

@di Ich sehe, dass Ihr Plan genehmigt ist. Bitte fahre fort!

@di warnt vor einer möglichen Verzögerung bei der Veröffentlichung .

Falls ich nicht verfügbar bin, wenn wir 20.3 veröffentlichen können (was hoffentlich nächste Woche der Fall sein wird), hier ist ein Werbeplan .

Wie ich an anderer Stelle in einem Kommentar besprochen habe, haben wir uns entschieden, die Veröffentlichung etwas zu verschieben, da einige CI-Probleme auftauchten und einige externe Faktoren hinzukamen.

In der heutigen Teambesprechung haben wir uns darauf geeinigt, dass die Veröffentlichung von 20.3 voraussichtlich morgen oder am Freitag erfolgen wird. Folgen Sie #8936 für mehr.

Ich habe nicht so viel Reichweite pro Paket betrieben, wie ich in einem früheren Kommentar vorgeschlagen hatte. Aber das bedeutet nicht, dass wir keine Öffentlichkeitsarbeit geleistet haben. Einige der Einsätze, die wir durchgeführt haben (einige davon sind in #8511 oder auf dieser Wiki-Seite katalogisiert):

• Podcasts: Podcast.__init__ , Test & Code , FLOSS Weekly , Software Developers Journey , Real Python
• Ein Haufen Tweets
• Ein kurzes YouTube-Video zu den Änderungen
• E-Mails an PyCon-, PSF- und PyPI-Sponsoren von ihrem PSF-Sponsoring-Kontakt, mit der Bitte, ihre technischen Abteilungen über bevorstehende Änderungen zu informieren
• E-Mail an pypi-announce und ähnliche Listen
• Blogbeiträge wie dieser
• E-Mail an Civic Tech und ähnliche Gruppen/Think Tanks

In den letzten Monaten haben wir einen stetigen Strom neuer Probleme von Leuten erhalten, die den neuen Resolver in 20.2 und 20.3 Beta, Pip 20.3b1, getestet haben . Diese Berichte haben uns geholfen, den Resolver zu verbessern, Fehler zu beheben und die UX seiner Ausgabe zu verbessern. Wir haben auch das Benutzerhandbuch „Was ändert sich“ erheblich verbessert , teilweise als Reaktion auf Beta-Feedback.

Hier mein grober Plan:

* Start a discussion on discuss.python.org asking for support

* Direct folks to a Slack channel that could serve as a communication channel between everyone

* Start a document outlining some FAQ and our responses

* Include a decision tree for new issue -> triaged issue

* Share this with the channel once we have a known release date

* Try and roughly schedule volunteers to be online & triaging in the days following the release

@di Ich erkenne, dass die ständige Unsicherheit und Verzögerungen Sie wahrscheinlich davon abgehalten haben, die Planung durchzuführen. Der neue Veröffentlichungstermin ist morgen, Montag, der 30. November. Wenn Sie jetzt einen Diskussionsthread und einen Entscheidungsbaum zum Teilen haben, machen Sie bitte weiter und teilen Sie sie!

pip 20.3 wurde veröffentlicht und hat standardmäßig den neuen Resolver! Hier ist die Release-Ankündigung im PSF-Blog: https://blog.python.org/2020/11/pip-20-3-release-new-resolver.html