4799 ist der Ort, an dem ein Großteil der Debatte stattfindet. Es wurde hauptsächlich ausgelöst durch:

1. Ich habe verstanden, dass der einzige ausstehende Blocker für die PEP 518-Unterstützung #4764 war (über https://github.com/pypa/pip/pull/4144#issuecomment-302711736)
2. Dann tauchte #4799 auf, und ich sah es mir an, um zu sehen, ob ich einen Sinn für all die laufenden Arbeiten von @xoviat erkennen konnte.
3. Im Zuge dessen tauchte #4647 als Release-Blocker auf, der besagte, dass die PEP 518-Unterstützung unterbrochen sei.

Als ich versuchte, herauszufinden, was @xoviat in #4799 sagte, wurde es offensichtlich, dass wir einige Probleme mit dem rekursiven Erstellen von Build-Umgebungen hatten (X braucht Y zum Erstellen und Y braucht Z, ...), obwohl ich ' Ich bin mir immer noch nicht sicher, ob es sich dabei um Implementierungsfehler, tiefere Designprobleme oder böse Eckfälle handelt, die wir ohne allzu große Probleme aufschieben können.

Ich persönlich bin an dem Punkt, wo ich überfordert bin. Ich verstehe die Implementierung von @xoviat nicht, um zu beurteilen, ob sie benötigt wird oder ob wir immer noch #4764 zusammenführen und #4647 reparieren müssen, um einsatzbereit zu sein. Ich weiß auch nicht, wie einfach es sein wird, #4647 zu beheben ( @xoviat scheint zu sagen, dass wir #4799 zusammenführen müssen, um #4647 zu beheben, aber das bringt seine eigenen Probleme mit sich).

Ich habe an diesem Wochenende keine Zeit und keine Energie mehr, um die Diskussion weiterzuführen, also breche ich an dieser Stelle (zumindest für eine Weile) ab. Für mich ist der entscheidende Punkt, dass wir ein akzeptables Maß an PEP 518-Unterstützung für Pip 10 wollen. Ich möchte, dass mir jemand ein Gefühl dafür gibt, ob wir es fast geschafft haben oder ob wir noch Wochen entfernt sind, damit ich kann es vermeiden, die Leute aufzuregen, dass Pip 10 kommt, nur um dann zu sagen, dass es nicht vor dem neuen Jahr sein wird ...

Danke für eine sehr hilfreiche Zusammenfassung @pfmoore.

@ncoghlan @dstufft @xoviat Können wir bitte die Diskussion hierher bringen? Es auf einer geschlossenen PR zu tun, fühlt sich für mich komisch an. ._.

Sichere Sache.

@pradyunsg Ich weiß, dass du dafür keine Zeit hast. Aber Sie waren erfolgreicher darin, PRs genehmigt zu bekommen als ich, also werde ich Sie gerne durch die aktuelle Implementierung führen, wie sie funktioniert und welche potenziellen Probleme damit verbunden sind. Ich werde erklären, wie ich einige (aber nicht alle) dieser Probleme gelöst habe, und meine Ideen für eine vollständige Behebung (was ich wiederum nach PEP 517 tun kann, wenn dies nicht der Fall ist). Es ist mir ehrlich gesagt egal, wer die Arbeit macht, solange sie erledigt ist.

Eigentlich bist du AWOL, also lass mich eine Zusammenfassung schreiben:

pip hat eine Objekthierarchie, wie es in den meisten Python-Projekten üblich ist. Das alles startet den Befehl, der neue Verweise auf Objekte erstellt, die neue Verweise auf niedrigere Objekte erstellen. Es ist wie ein Baum.

Ich werde den "Umfang" eines Objekts als eine Art Lebensdauer definieren. Es ist die Dauer, die ein Objekt existiert. Im Moment ist der Bereich von PEP 518 in pip der WheelBuilder . Die PEP 518-Umgebung wird für bdist_wheel eingerichtet, dann wird bdist_wheel in dieser Umgebung ausgeführt, und dann wird die Umgebung abgebaut.

Was ist also das Problem daran? Das Problem besteht darin, dass der Umfang der PEP 518-Umgebung gleich oder größer sein muss als der Umfang aller Aufrufe von setup.py . Genauer gesagt muss es ein Objekt kapseln, das während der Dauer von setup.py -Aufrufen existiert. Dieses Objekt ist Requirement .

Die erste offensichtliche Entscheidung, der Sie begegnen werden, ist: Was sollte einen Bezug zu BuildEnvironment haben, und Requirement ist ein guter Ort wie jeder andere. Tatsächlich ist es IMHO der beste Ort, um die Referenz zu platzieren, da setup.py genau dann aufgerufen wird, wenn Requirement existiert.

Das nächste Problem, auf das Sie möglicherweise stoßen, ist Folgendes: Wie installieren wir die BuildEnvironment -Anforderungen? Wir könnten einfach pip . Und das ist die Entscheidung, die vom ursprünglichen Implementierer getroffen wurde. Aber damit gibt es ein Problem: pip kann nicht wissen, wie viele Shell-Aufrufe es macht, weil jedes pip sich selbst erneut aufrufen könnte. Tatsächlich könnte ein in böser Absicht konstruiertes Paket mit zirkulären Abhängigkeiten den Computer von jemandem zum Absturz bringen, wenn pip zu viele Prozesse erzeugt.

Ein weiteres Problem ist, welchen Shell-Aufruf sollen wir machen? Es ist tatsächlich schwieriger als Sie vielleicht denken, denn das Abrufen der Befehlszeilenparameter ist ehrlich gesagt ein PITA, bei dem Sie diesen Aufruf tätigen müssen. Daher haben Sie möglicherweise Probleme, die ursprünglichen Parameter zu übergeben, die der Benutzer an das Kind übergeben hat. Die vom ursprünglichen Implementierer verwendete Lösung beinhaltete die Verwendung von finder , aber ich denke, Sie kennen das Problem damit.

Ein Kind von sich selbst ohne eine Art Manager-Klasse zu berappen, die Kinder töten kann, wenn der Benutzer Strg + C drückt, ist nicht nur falsch, es ist bösartig, insbesondere wenn Sie nicht wissen, wie viele Prozesse Sie erzeugt haben. Ich persönlich weiß nicht, ob die Kinder in der aktuellen Implementierung sterben (dies könnte FUD sein), aber wenn sie dies nicht tun, ist die aktuelle Implementierung meiner Meinung nach falsch (abgesehen von den anderen Bedenken).

Einige mögliche Lösungen für dieses Problem sind die folgenden:

1. Wenn Sie PEP 518 aus der Tür bekommen wollen, ist Ihre beste Wahl wahrscheinlich eine Art Sperrdatei, die nur bis zu 10 Sperren oder so zulässt, um sicherzustellen, dass Pip nicht unendlich multipliziert wird. Dann können Sie einfach die genauen Anforderungen zusammen mit den Befehlszeilenargumenten an das untergeordnete Element weitergeben.

2. Eine geeignete Lösung, die ich nach PEP 517 implementieren möchte, besteht darin, eine Klasse BuildEnvironmentManager zu haben, die direkt im Befehl install initialisiert wird. BuildEnvironmentManager hätte einen Verweis auf alle dortigen Objekte ( RequirementPreparer , WheelBuilder usw.) und hätte eine einzige Methode: get_build_environment(requirement_set) . Sie könnten dann eine Methode auf RequirementPreparer implementieren, die so etwas wie set_build_environment_manager ist, die dann zum Abrufen von Build-Umgebungen verwendet werden kann. Das BuildEnvironmentManager könnte sogar mehrere Verwendungen derselben Umgebung erkennen (am häufigsten ['setuptools', 'wheel'] ) und dieselbe Umgebung bereitstellen, wenn sie mehrmals benötigt wird, sodass Sie sie nicht erstellen müssen (anfangs sehr häufig mit Projekten ohne pyproject.toml ). Idealerweise gäbe es auch ein OOP-Design, um zu versuchen, die Zirkelbezüge zu entfernen (nicht trivial).

@xoviat Obwohl es möglicherweise nicht den Fall absichtlicher Bosheit abdeckt, gehe ich richtig in der Annahme, dass ein Build-Cache (der verwendet wurde, selbst wenn --no-binary :all: angegeben wurde) mit der Fähigkeit, nicht nur abgeschlossene Builds zu verfolgen, sondern auch in -Fortschritt, würde ausreichen, um sicherzustellen, dass Build-Abhängigkeitszyklen beendet werden? Dies wäre eine Variante Ihres ersten Vorschlags (ein prozessübergreifendes Limit für die Anzahl gleichzeitiger Pip-Aufrufe), aber neu formuliert als:

1. Nur ein Prozess auf einer Maschine darf zur gleichen Zeit dasselbe Paket erstellen
2. Es gibt eine "Build-ID" der obersten Ebene, die pip an alle untergeordneten Builds weitergibt, die es erzeugt (z. B. die PID des Prozesses der obersten Ebene in Kombination mit dem Namen des zu erstellenden Pakets).
3. Wenn der Build-Cache anzeigt, dass etwas von einer anderen Build-ID erstellt wird, warten Sie, bis dieser Build abgeschlossen ist
4. Wenn der Build-Cache anzeigt, dass bereits etwas für dieselbe Build-ID erstellt wird, brechen Sie mit einem Fehler ab, der die zirkuläre Abhängigkeit meldet und angibt, dass --binary <name> erforderlich sein wird, damit der Build funktioniert

pip müsste auch den Vorschlag von @pfmoore implementieren, setuptools und wheel von der Standardlogik auszunehmen, dass sowohl setuptools als auch wheel benötigt werden.

Es ist keine schlechte Idee, die Diskette zu verwenden, um OOP-Entwurfsprobleme nicht lösen zu müssen. Das ist wie eine Zwischenoption zwischen der vollständigen Implementierung von PEP 518 und dem einfachen Zusammenhacken von etwas.

Es würde auch gut mit containerisierten Umgebungen und Chroots im Allgemeinen interagieren, da wir in der Lage wären, Tools auf Betriebssystemebene zu verwenden, um verschiedene Builds auf Python-Ebene voneinander zu isolieren, sodass pip nur herausfinden müsste, wie es seine eigenen Unterprozesse sicherstellt kooperieren miteinander.

@xoviat danke für die obige Zusammenfassung. Wie gesagt, ich habe die Grenze meines Verständnisses des Codes in diesem Bereich erreicht, und Ihre Erklärung hat mir enorm geholfen.

Ich hatte mir den Code von #4144 vorher noch nicht angesehen. Ich habe es gerade getan und ich möchte wirklich nicht, dass es verschickt wird.

PEP 518 völlig korrekt implementieren und einfach etwas zusammen hacken.

Ehrlich gesagt denke ich, dass es darauf ankommt. Die vollständige und ordnungsgemäße Implementierung von PEP 518 ist eine Aufgabe, die Pip 10 ein (ziemlich) bisschen verzögern würde/könnte, wenn wir diesen Weg gehen.

Ich denke, ein sicherer Mittelweg wäre hier, zu verlangen, dass Build-Abhängigkeiten als Räder verfügbar sind. Auf diese Weise können wir das Rekursionsproblem vermeiden, da die Build-Abhängigkeiten (und alle ihre Abhängigkeiten) nicht über diesen Prozess erstellt werden müssten.

Wie klingt das?

Es ist eingeschränkt, aber ich denke, eine eingeschränkte erste Implementierung ist besser als eine erste Implementierung, bei der man sich selbst in den Fuß schießen kann, wenn man nicht aufpasst.

Die vollständige und ordnungsgemäße Implementierung von PEP 518 ist eine Aufgabe, die Pip 10 ein (ziemlich) bisschen verzögern würde/könnte, wenn wir diesen Weg gehen.

Danke für die Bestätigung - das war meine Befürchtung.

Jetzt bin ich jedoch verwirrt, da ich dachte, dass zumindest teilweise PEP 518 bereits im Master war. Genauer gesagt, so wie ich es verstehe, zeigt #4647 einen Fehler in der PEP 518-Unterstützung im Master - also haben wir eindeutig schon etwas , da was auch immer es ist, nicht korrekt ist ...

Also müssen wir etwas tun, und es scheint, als wären die Optionen:

1. Reißen Sie alles heraus, was wir im Moment für PEP 518-Unterstützung haben.
2. Räumen Sie auf, was wir haben, und versenden Sie teilweise Unterstützung.
3. Implementieren Sie PEP 518 vollständig, bevor wir Pip 10 veröffentlichen.

Wie Sie sagen, bedeutet (3) eine lange Verzögerung vor Pip 10, und wir haben andere Korrekturen, die ich wirklich gerne veröffentlicht sehen würde (Unicode-Korrekturen sind eine, bei der wir regelmäßig Probleme bekommen). Also darauf habe ich keine Lust. Sie haben (1) nicht erwähnt, und ich bin mir nicht sicher, ob das daran liegt, dass Sie dachten, wir hätten keine PEP 518-Unterstützung, oder ob Sie davon ausgegangen sind, dass ein Rückzug keine Option wäre. Mir persönlich gefällt die Idee nicht - es ist ein Rückschritt und sendet eine ziemlich negative Botschaft über das PEP selbst aus, wenn es so schwer ist, es richtig zu implementieren. Aber ich denke, wir sollten es ausdrücklich ablehnen.

Ihr Vorschlag für (2), dass wir eine Version von PEP 518 ausliefern, die nur Räder als Build-Abhängigkeiten unterstützt (wir müssten noch #4647 beheben, da die Demonstration davon eine Build-Abhängigkeit verwendet, die ein Rad ist), erscheint vernünftig , in dem Sinne, dass es für uns praktisch umzusetzen ist. Mein Hauptvorbehalt ist, dass ich keine Ahnung habe, wie problematisch diese Einschränkung für Leute wäre, die PEP 518 verwenden möchten.

Ich denke, ich habe das Gefühl, dass wir feststecken, was auch immer wir tun, aber eine teilweise Unterstützung, die nur Räder abdeckt, da Build-Abhängigkeiten die beste Option aus einem schlechten Los sind :-(

Die PEP-Autoren (in https://github.com/pypa/pip/pull/4799#issuecomment-338331267 und https://github.com/pypa/pip/pull/4799#issuecomment-338332575 als Antwort auf meine Frage in https://github.com/pypa/pip/pull/4799#issuecomment-338325354) waren sich ziemlich sicher, dass die vollständige PEP-Unterstützung den Aufbau von Build-Abhängigkeiten erfordert, also muss es nur eine Notlösung sein.

Aber ich bin es nicht, der das umsetzen wird, also lasse ich mich gerne auf das Urteil dessen ein, der es tut. Eine Sache, die ich getan habe, ist, #4803 zu erstellen und es als Release-Blocker zu markieren, als Erinnerung daran, dass wir dokumentieren sollten, wie wir von der Spezifikation abweichen, wenn dies erforderlich ist.

(Und nicht zum Thema, aber kann ich vorschlagen, dass wir darauf achten, nicht die gleichen Fehler zu machen, wenn wir mit der Implementierung von PEP 517 beginnen? Stellen wir sicher, dass wir alle Implikationen der Implementierung verstehen, bevor wir zu tief in die Codierung einsteigen - mein Instinkt ist, dass PEP 517 ein noch komplexeres Designproblem sein wird als PEP 518 ...)

Ich bin am vertrautesten mit Distributionen, wenn es um die Perspektive „Alles aus dem Quellcode erstellen“ geht, und wir trennen den Prozess des „Bootstrappings der Buildroot“ definitiv von dem der regulären Paketerstellung. Vollständiges automatisches Bootstrapping von der Quelle ist schwierig , da Sie am Ende Dinge wie das Bootstrapping Ihres C-Compilers tun müssen.

Also für pip denke ich, dass es vernünftig ist zu sagen, dass Build-Abhängigkeiten immer von Wheel-Dateien installierbar sein werden. Die Verfeinerung, die Sie nach 10.x einführen können, besteht darin, einen Build-Cache zu haben, der sich vom regulären Rad-Cache unterscheidet, sodass Benutzer des Caches sicher sein können, dass alle darin enthaltenen Räder in einer kontrollierten Umgebung erstellt wurden, anstatt von PyPI heruntergeladen zu werden oder einem anderen Indexserver.

Mir persönlich gefällt die Idee nicht - es ist ein Rückschritt und sendet eine ziemlich negative Botschaft über das PEP selbst aus, wenn es so schwer ist, es richtig zu implementieren.

Dem stimme ich nicht unbedingt zu. Es ist schwierig, es für Pip richtig zu implementieren. Aber Pip, wie im PEP angegeben, ist eines der wenigen Frontends, das die Leute verwenden werden. Ich denke, es ist unsere Aufgabe als Sprachimplementierer, und pip ist wirklich eine Sprache, die Leute verwenden, um ihre Python-Projekte zu verpacken, um es so einfach wie möglich zu machen, ein Build-System zu erstellen, ohne über all diese schwierigen Probleme nachdenken zu müssen. Für sie sollte es einfach reibungslos funktionieren, weil wir die harte Arbeit geleistet haben.

Ich denke, ein sicherer Mittelweg wäre hier, zu verlangen, dass Build-Abhängigkeiten als Räder verfügbar sind.

Eigentlich macht #4799 genau das. Wenn Sie möchten, kann ich diesen Zweig wiederherstellen, und Sie können ihn forken und als PR einreichen.

Zwei Dinge auf der Implementierungsseite der Dinge von (2) stehen jedoch noch aus - wie @xoviat oben darauf hingewiesen hatte:

1. Herausfinden, wie der Teilprozess erstellt wird (Argumente et al.)
   Ich denke, sollte machbar sein.

2. welche Paketversionen installiert werden sollen.
   Dies sollte wahrscheinlich im selben übergeordneten Prozess erfolgen, obwohl ich mir nicht sicher bin, wie genau das passieren würde, da der aktuelle Resolver-Code immer noch mit Code in pip._internal.operations.prepare verflochten ist. Ich probier das diese Woche mal aus.

Ich bin mir aber nicht sicher, wer die Zeit dafür haben würde.

es sendet eine ziemlich negative Botschaft über das PEP selbst, wenn es so schwer ist, es richtig zu implementieren.

Es ist wahrscheinlich nicht schwer, es richtig zu implementieren. Es ist nur so, wie die Codebasis von pip heute ist, es ist nicht trivial, sie in pip zu implementieren – es gibt Dinge, die an seltsamen Orten passieren, und ich denke, wenn das bereinigt wird, wäre es ziemlich trivial.

Sie haben (1) nicht erwähnt, und ich bin mir nicht sicher, ob das daran liegt, dass Sie dachten, wir hätten keine PEP 518-Unterstützung, oder ob Sie davon ausgegangen sind, dass ein Rückzug keine Option wäre.

Ich bin davon ausgegangen, dass ein Rückzug keine Option ist.

Jetzt, wo ich darüber nachdenke – wie wichtig ist es, PEP 518 in Pip 10 zu versenden? Ich denke, wenn es auf die nächste große Veröffentlichung verschoben werden kann, wäre das (abgesehen davon, dass es der einfache Ausweg aus dieser Situation ist) unkompliziert und beide 517 + 518 könnten in einer großen Veröffentlichung landen. Das fühlt sich sauber genug an, dass ich nicht derjenige sein werde, der sagt, dass dies nicht der richtige Weg ist.

@dstufft @xavfernandez Gedanken?

@ncoghlans Idee eines Build-Cache klingt für mich nach einer guten Idee, obwohl ich nicht sicher bin, ob ich alle Auswirkungen verstehe.

Wenn Sie möchten, kann ich diesen Zweig wiederherstellen, und Sie können ihn forken und als PR einreichen.

Ich werde wahrscheinlich nicht die Zeit haben, und selbst wenn ich es tun sollte, werde ich möglicherweise keine vorhandenen Commits wiederverwenden. Aber diesen Zweig wiederherzustellen, kann nicht schaden. :)

Mein Hauptvorbehalt ist, dass ich keine Ahnung habe, wie problematisch diese Einschränkung für Leute wäre, die PEP 518 verwenden möchten.

Wir hatten genau diese Diskussion, außer dass Sie es wahrscheinlich nicht einmal wussten. Diese Situation ist Situation X. Das Aufrufen von egg_info vor dem Einrichten der Build-Umgebung ist Situation Y (#4799).

Aber ich bin es nicht, der das umsetzen wird, also lasse ich mich gerne auf das Urteil dessen ein, der es tut.

Ich denke, das bedeutet, dass # 4799 dann wieder auf dem Tisch ist? Solange es alle Tests besteht und hält, was es verspricht?

Aargh, diese X's und Y's kommen zurück, um mich wieder zu verfolgen :wink: Ja, ich sage, ich habe kein Gefühl für die relativen Wahrscheinlichkeiten der 2 Fälle. Ich verstehe, dass Sie sagen, dass Build-Anforderungen, die keine Räder sind, selten genug sind, dass wir diesen Fall ignorieren können. Also gab es im Grunde genommen eine „ist ok“- und eine „weiß nicht“-Abstimmung zwischen uns. Ich versuche nicht, diese Option zu blockieren, sondern sage nur, wo die Grenzen meiner Intuition liegen, das ist alles.

@xoviat Ich habe ein paar Fragen. Es wäre toll, wenn du sie beantworten würdest, bevor du eine neue PR machst. :)

• Wie werden Sie feststellen, welche Pakete installiert werden?
• Werden Sie sich auf reine Binär-Build-Abhängigkeiten beschränken?

Ich habe mit vielen wissenschaftlichen Projekten gearbeitet, also könnte es sein, dass ich voreingenommen bin. Aber ich kann eine Liste von Projekten mit Wheel-Build-Abhängigkeiten aufzählen und mir fällt wirklich kein Projekt mit Quellabhängigkeiten ein. Vielleicht bin ich falsch.

@rgommers wäre es für Sie in Ordnung, wenn PEP 518 nur Build-Abhängigkeiten unterstützt, die als Räder verfügbar sind, wenn es im nächsten Pip wäre?

Wie werden Sie feststellen, welche Pakete installiert werden?

Der Unterprozess ruft die Anforderungsliste genau wie angegeben ab. So geht es durch den Resolver.

Werden Sie sich auf reine Binär-Build-Abhängigkeiten beschränken?

Ja, deshalb ist der Test tatsächlich fehlgeschlagen. Die Build-Abhängigkeit im Test ist kein Rad.

Jetzt, wo ich darüber nachdenke – wie wichtig ist es, PEP 518 in Pip 10 zu versenden? Ich denke, wenn es auf die nächste große Veröffentlichung verschoben werden kann, wäre das (abgesehen davon, dass es der einfache Ausweg aus dieser Situation ist) unkompliziert und beide 517 + 518 könnten in einer großen Veröffentlichung landen. Das fühlt sich sauber genug an, dass ich nicht derjenige sein werde, der sagt, dass dies nicht der richtige Weg ist.

Was denken wir darüber, ob wir jemanden finden werden, der die Zeit hat, die PEPs 517 und 518 für Pip 11 zu machen? Ich bin nicht optimistisch. Es scheint mir, dass beides große Teile der Arbeit sind, und wir haben auch die Resolver-Arbeit im Gange. Ich bin zwar nicht dafür, Pip 10 länger als nötig aufzuhalten, aber ich fühle mich genauso unwohl, wenn wir alle unsere Pläne für wichtige Funktionen schwanken lassen, während wir eine Reihe von im Wesentlichen kleineren Versionen veröffentlichen.

Um es anders auszudrücken, die Aussage „Lass uns eine Pip-10-Veröffentlichung machen“ führte zu einem Wiederaufleben der Aktivität bei der PEP 518-Arbeit. Wenn wir das aus Pip 10 entfernen, werde ich mich darauf konzentrieren, die Dinge für die Veröffentlichung vorzubereiten, und ich vermute, dass PEP 518 wahrscheinlich wieder an Schwung verliert. Was soll die Dinge wieder in Gang bringen? @xoviat hat an der Implementierung gearbeitet, aber er hatte Probleme damit, den Rest von uns dazu zu bringen, die Probleme zu verstehen, mit denen er bisher zu kämpfen hatte. Ich möchte ihn nicht wieder ohne Feedback arbeiten lassen.

Was wir tun könnten, ist ein „Pip 9.1“ mit nur den inkrementellen Fixes zu veröffentlichen, die wir bereit haben, und die Versionsnummer „Pip 10“ für die Implementierung von (mindestens einem) der 3 großen Ticket-Features zu reservieren, die in der Pipeline sind. Aber wenn wir das tun, würde ich gerne versuchen[1], mich auf eine Pip-10-Veröffentlichung im ersten Quartal 2018 festzulegen. Ich wäre damit einverstanden. Aber hat irgendjemand ein Gefühl dafür, was es bedeuten würde, die teilweise Unterstützung, die wir derzeit im Master haben, zurückzuziehen? Oder indem wir dokumentieren, was wir haben und wo seine Einschränkungen liegen (damit die Leute nicht versuchen, es zu verwenden, vorausgesetzt, es ist vollständig, Fehler finden und Probleme aufwerfen, auf die wir mit „dieses Feature ist noch nicht vollständig, sorry, aber warte auf pip 10")? Tauschen wir nur einen großen Teil der Arbeit gegen einen anderen aus?

[1] In dem Maße, in dem wir uns mit äußerst begrenzten freiwilligen Ressourcen für alles einsetzen können, was wir zur Verfügung haben.

Ich habe mit vielen wissenschaftlichen Projekten gearbeitet, also könnte es sein, dass ich voreingenommen bin

Danke, es ist manchmal schwer, den Hintergrund von Leuten zu kennen. Wenn Sie die wissenschaftlichen Projekte kennen, lindert das meine Bedenken sehr.

Was wir tun könnten, ist ein „Pip 9.1“ mit nur den inkrementellen Fixes zu veröffentlichen, die wir bereit haben, und die Versionsnummer „Pip 10“ für die Implementierung von (mindestens einem) der 3 großen Ticket-Features zu reservieren, die in der Pipeline sind.

Das gefällt mir wirklich gut. +1 zu einem Pip 9.1.0 anstelle von Pip 10.0.0

Ich würde gerne versuchen[1], mich auf eine Veröffentlichung von Pip 10 im ersten Quartal 2018 festzulegen. Als Ansatz wäre ich damit einverstanden.

Ich hatte einen sehr interessanten Geistesblitz – Pip wird am 12. Oktober 2018 10 Jahre alt. Das wäre das perfekte Datum für eine Veröffentlichung von Pip 10.0.0. Es ist eine völlig andere Zeitlinie. Ich sage nicht, dass wir die White-Whale-Features bis dahin verschieben sollten, aber ein Teil von mir möchte wirklich, dass diese Versionsnummer und das Alter auch übereinstimmen.

Ich vermute, dass PEP 518 wahrscheinlich wieder an Schwung verliert.

Ich werde tun, was ich kann, um sicherzustellen, dass dies nicht der Fall ist. Hoffentlich ist @xoviat auch dazu bereit. :)

Hat jemand ein Gefühl dafür, was es bedeuten würde, die teilweise Unterstützung, die wir derzeit im Master haben, zurückzuziehen?

Ich habe nichts dagegen, morgen einen Blick darauf zu werfen. Da @dstufft derjenige war, der auf #4144 überprüft wurde, denke ich, dass sein Beitrag dazu wertvoll wäre.

Hinweis – Ich würde nichts so Drastisches tun wollen, wie Dinge ohne die Zustimmung von @dstufft und @xavfernandez rückgängig zu machen – also lasst uns auch sehen, was sie zu sagen haben.

@dstufft hat nicht genug Zeit am Tag. Er muss auch dafür sorgen, dass das Lager nicht untergeht.

Mal sehen, was sie zu sagen haben.

Ja bitte. :)

Aus UX-Perspektive: Dem „Trusting Trust“-Angriff umfassend entgegenzuwirken ist wirklich schmerzhaft [1], und Sie werden viele Leute finden, die sagen: „Ich kompiliere alles aus dem Quellcode“, tun dies nicht – irgendwo in ihrem Prozess wird ein Bootstrap-Schritt sein, bei dem sie einer Binärdatei vertrauen, die entweder von jemand anderem (z. B. der Laufzeitumgebung und der Build-Toolchain von ihrem Betriebssystemanbieter) oder von einer früheren Generation ihrer eigenen Plattform (z. B. den Buildroots für neue Versionen von Fedora und RHEL wird von früheren Versionen von Fedora und RHEL gesät, sie beginnen nicht komplett von vorne). Sogar eine quellbasierte Linux-Distribution wie Gentoo beginnt mit einem Installationsprogramm, um Ihnen eine funktionierende Build-Umgebung mit einem Linux-Kernel, C-Compiler, Hardwaretreibern usw. zu bieten.

Daher denke ich, dass es für Pip 10 völlig vernünftig ist zu sagen, dass --no-binary :all: nur für Laufzeitabhängigkeiten gilt, nicht um Abhängigkeiten zu erstellen. Wenn Leute ihre Buildroot explizit aus der Quelle erstellen möchten, können sie dies immer noch tun - es ist nur so, dass Pip 10 dies aufgrund der inhärenten rekursiven Bootstrapping-Probleme nicht implizit für sie automatisieren wird, wenn es darum geht, implizite Quell-Builds für Ihre Build-Abhängigkeiten zuzulassen.

Damit die Leute angeben können, dass sie erwarten, dass die Build-Umgebung vollständig vorkonfiguriert ist, wäre es sinnvoll, eine separate --no-implicit-builddeps -Option hinzuzufügen, damit die Installation sofort fehlschlägt, wenn implizites binäres Bootstrapping als Teil eines Quell-Builds erforderlich ist . Auf diese Weise können Leute, die sicherstellen möchten, dass alles aus dem Quellcode erstellt wird (einschließlich der Build-Abhängigkeiten), Folgendes tun:

pip install --no-binary :all: --no-implicit-builddeps -r build-requirements.txt
pip install --no-binary :all: --no-implicit-builddeps -r requirements.txt

Und definieren Sie so viele verschiedene Installationsgruppen wie nötig, um zu einem Punkt zu gelangen, an dem die erste nichts anderes als CPython und alle vorinstallierten Nicht-Python-Build-Toolchains benötigt.

Eine potenzielle zukünftige Ergänzung zu diesem Konzept wäre es, den Leuten zu erlauben, --buildenv <path> zu sagen, um eine vorkonfigurierte Build-Umgebung anzugeben, die für alle erforderlichen Quell-Builds verwendet werden kann, anstatt jeden Build in einer isolierten Umgebung durchzuführen. Ich würde jedoch nicht versuchen, das in Pip 10 zu bringen - ich würde vorschlagen, 10.x auf den glücklichen Pfad "binäre Build-Abhängigkeiten sind zulässig" und die alternative Option "Build fehlschlagen, wenn eine binäre Build-Abhängigkeit erforderlich ist" zu beschränken und ist im aktuell laufenden Interpreter noch nicht verfügbar".

[1] https://www.schneier.com/blog/archives/2006/01/countering_trus.html

Ich habe an eine andere Option gedacht, die vernünftig erscheint und nicht zu viel Refactoring erfordern würde: im Wesentlichen die Verwendung von Multithreading, um den Haupt-Thread anzuhalten, während die Build-Umgebung eingerichtet wird. Die Idee ist ungefähr so: In install.py hätten Sie ein BuildEnvironmentManager :

class BuildEnvironmentManager(Thread):
    '''Has references to literally everything (cache, resolver, etc.)'''
    def run(self):
        while True:
            requirement_list, future = self.build_environment_queue.get()

            # install the requirements using all of the things
            # that we have

            # then put the build environment in the future
            future.put(BuildEnvironment())

Sie hätten dann eine andere Datei (ich verwende backend.py, weil sie nicht voll genug ist und wahrscheinlich mehr Dinge darin verwenden könnte, und sie befindet sich am unteren Ende des Baums):

class Future(Queue):
    pass

class BuildEnvironmentQueue(object):
    def __init__(self):
        self._queue = Queue()

    def request_build_environment(self, requirement_list):
        f = Future()
        self._queue.put((requirement_list, f))
        return f.get()

    def get():
        return self._queue.get()

Und in operations/prepare.py:

# This call will put the thread to sleep until we have a build environment
# with the requirements installed
self.build_environment_queue.request_build_environment(requirement_list)

Dies hat den Vorteil, dass nur minimales Refactoring erforderlich ist, eine serialisierte BuildEnvironmentManager vorhanden ist (damit die Build-Umgebungen optimiert werden können und Sie genau wissen, welche Anforderungen in einem einzelnen Objekt gestellt wurden) und alles in einem Prozess enthalten ist (also die Worst-Case-Szenario ist ein Deadlock). Natürlich müsste die Protokollierung für die anderen Threads deaktiviert werden, aber das ist kein allzu großes Problem.

Beantwortung meiner eigenen Frage zum queue.Queue-basierten Ansatz: Es ist am besten, sich nicht auf concurrent.futures zu verlassen, da dies die Bereitstellung von https://pypi.org/project/futures/ in Python 2.7 erfordern würde.

Ohne die Codebasis von pip gut zu kennen, scheint die Idee, die Verwaltung der Build-Umgebung an einem einzigen Ort zu konsolidieren, immer noch eine attraktive Option zu sein.

concurrent.futures ist für diesen Ansatz nicht erforderlich. Future ist nur ein aussagekräftigerer Wrapper.

Das einzige erforderliche Primitiv ist eine Warteschlange: https://docs.python.org/2/library/queue.html

Ich schätze, wir können diese Zeilen einfach in die BuildEnvironmentManager verschieben.

Ich habe mit vielen wissenschaftlichen Projekten gearbeitet, also könnte es sein, dass ich voreingenommen bin. Aber ich kann eine Liste von Projekten mit Wheel-Build-Abhängigkeiten aufzählen und mir fällt wirklich kein Projekt mit Quellabhängigkeiten ein. Vielleicht bin ich falsch.

Nun, zum einen gibt es jedes Betriebssystem, das nicht [Windows, macOS, Linux] ist, IIRC, diese werden nicht von manylinux1 abgedeckt.

@rgommers wäre es für Sie in Ordnung, wenn PEP 518 nur Build-Abhängigkeiten unterstützt, die als Räder verfügbar sind, wenn es im nächsten Pip wäre?

Nicht mein Ding, aber ich würde mich über jeden Schritt nach vorne hier freuen. Die PEP 518-Unterstützung ist sowieso optional, daher ist es in Pip 10 immer noch eine signifikante Verbesserung, wenn es nur funktioniert, wenn Räder verfügbar sind (deckt > 90% der Fälle ab, würde ich sagen).

Beachten Sie, dass selbst Plattformen, die keine Wheels auf PyPI zulassen, immer noch einen lokalen Wheel-Cache haben, was bedeutet, dass pip, selbst wenn pip Dinge nicht implizit booten kann, sie möglicherweise immer noch ausdrucken und sagen kann: „Installieren Sie diese Build-Abhängigkeiten irgendwie , und dann wird das funktionieren".

Aber hat irgendjemand ein Gefühl dafür, was es bedeuten würde, die teilweise Unterstützung, die wir derzeit im Master haben, zurückzuziehen?

Ich habe mir das angesehen; es scheint nicht allzu schwer zu sein. Ich mache gerne eine PR dafür, wenn wir uns für diesen Weg entscheiden.

+1 zu einem Pip 9.1.0 anstelle von Pip 10.0.0

Ich habe endlich Zeit, den distutils-sig-Thread richtig zu lesen und mir relevante PRs und Diskussionen anzusehen (#4351, #4144, #4799 und ein paar andere). Ich denke jetzt, seit wir Pip 10 angekündigt haben; das sollten wir tun, mit der teilweisen PEP 518-Unterstützung – nein 9.1.0.

diese Versionsnummer und das Alter stimmen überein

Schade. :(

@ncoghlan Vielleicht ist dieser Kommentar unter das Radar gerutscht – https://github.com/pypa/pip/pull/4799#issuecomment -338416543

Falls dies nicht der Fall ist, wäre es nett, wenn Sie erklären könnten, warum es nicht funktionieren würde, da ich diese Art von Setup irgendwie verstehe und definitiv offen dafür bin, mehr darüber zu erfahren. :)

@pradyunsg Ich denke, das würde meistens funktionieren, da es sich um eine spezifische Implementierung der Build-Cache-Idee handelt. Der einzige Aspekt, den es nicht abdeckt, sind Build-Abhängigkeitsschleifen, da es keine Möglichkeit gibt, zu erkennen, "Ich wurde gerade gebeten, etwas zu bauen, das ich bereits versuche zu bauen".

Beachten Sie, dass pip Abhängigkeitsschleifen nicht auf magische Weise auflösen muss – es muss sie nur erkennen und fehlschlagen, sobald es eine entdeckt, anstatt tatsächlich in eine Endlosschleife zu gehen.

es deckt nicht ab, wie Abhängigkeitsschleifen erstellt werden,

Das würde bei rein binären Build-Abhängigkeiten nicht auftreten?

@pradyunsg Der verlinkte Kommentar betraf eine Möglichkeit, Quell-Builds für Build-Abhängigkeiten zuzulassen, was bedeutet, dass zirkuläre Abhängigkeiten zu einem potenziellen Problem werden. Wenn wir binäre Abhängigkeiten benötigen, kann sich pip vorerst einfach auf den vorhandenen Wheel-Cache verlassen.

Ah richtig. Danke! :)

Ich bin für einen Pip 10 mit einer partiellen PEP 518-Implementierung, die nur auf binäre Build-Abhängigkeiten beschränkt ist (oder bereits im Pip Wheel-Cache verfügbar ist), wenn das alles ist, was wir einschließen können.

Ich habe noch nicht den ganzen Thread gelesen, aber ich möchte nur darauf hinweisen, dass eine Nebenwirkung der Beschränkung auf binäre Build-Abhängigkeiten sein wird, dass es in vielen Fällen unmöglich ist, eine C-Abhängigkeit in Ihren Build-Deps zu haben. Ja, wir haben Binärräder unter Windows, macOS und einigen Linux-Versionen, aber nicht unter:

• Jedes Linux, das glibc nicht verwendet (Alpine Linux innerhalb von Docker ist ein beliebtes).
• Jedes *nix-Betriebssystem, das kein Linux ist, wie FreeBSD usw.

Dies würde bedeuten, dass beispielsweise jedes CFFI-basierte Projekt entweder PEP 518 nicht verwenden könnte oder auf diesen Plattformen deinstallierbar wäre.

Das wurde vielleicht schon angesprochen! Ich werde diesen Thread später lesen.

@dstufft Das ist richtig. Wir schlagen jedoch vor, dass die Verwendung des Pip-Cache eine Option ist. Sie können also Ihre Build-Abhängigkeiten zuerst pip wheel oder pip install erstellen und dann werden sie im Cache gespeichert.

Das wurde vielleicht schon angesprochen!

NÖ. :)

Dies würde bedeuten, dass beispielsweise jedes CFFI-basierte Projekt entweder PEP 518 nicht verwenden könnte oder auf diesen Plattformen deinstallierbar wäre.

In der Tat. :-(

Der Weg, um das in meinem Kopf zu umgehen, wäre, dass wir das PEP 518-Verhalten Opt-in machen könnten – wenn es eine pyproject.toml -Datei gibt, verwenden wir die Isolation + Build-Umgebung, ansonsten greifen wir auf das aktuelle Verhalten der Verwendung von setup.py zurück.

Ich werde diesen Thread später lesen.

Bitte. :)

Ich hatte genau denselben Kommentar wie Donald; Mein Verständnis von diesem Thread ist, dass nur Binärdateien vorübergehend sind, da keine Zeit ist, sie für Pip 10 zu implementieren. Richtig?

Wenn es stattdessen als dauerhafte Entscheidung vorgeschlagen wurde, dann natürlich -1.

Ich hatte genau denselben Kommentar wie Donald; Mein Verständnis von diesem Thread ist, dass nur Binärdateien vorübergehend sind, da keine Zeit ist, sie für Pip 10 zu implementieren. Richtig?

Das ist richtig. pip sollte Quellabhängigkeiten unterstützen, aber wir haben zu wenig Arbeitskräfte.

Der Weg, um dies in meinem Kopf zu umgehen, wäre, dass wir das PEP 518-Verhalten Opt-in machen könnten - wenn es eine pyproject.toml-Datei gibt, verwenden wir die Isolation + Build-Umgebung, ansonsten greifen wir auf das aktuelle Verhalten der Verwendung von setup.py zurück.

Ich habe diesen Kommentar noch einmal gelesen und werde hier widersprechen. PEP 518-Unterstützung sollte meiner Meinung nach nicht optional sein (aus Implementierungsgründen im Zusammenhang mit PEP 517), aber Projekte sollten auf diesen Plattformen nicht deinstallierbar werden.

Genauer gesagt, das bestimmte Projekt, das Sie installieren, sollte nicht bestimmen, ob Sie PEP 518 erhalten. Dies sollte dadurch bestimmt werden, ob Ihre Build-Abhängigkeiten als Räder oder im Cache verfügbar sind. Außerdem können wir die PEP 518-Unterstützung auch für diese Plattformen obligatorisch machen, wenn wir einfach eine Nachricht wie die folgende ausspucken:

Error: build dependency X is not in the pip cache. Run "pip install X" before installing Y.

Zusammenfassend meine eigene Sichtweise:

1. Ich betrachte die „Keine implizite Build-Unterstützung für Build-Abhängigkeiten“ als vorübergehende Einschränkung in Pip 10, um zu verhindern, dass bestimmte Klassen von Problemen (z. B. Build-Abhängigkeitsschleifen) in der ersten veröffentlichten Iteration des Features auftreten. Zukünftige Iterationen der Pluggable-Build-Backend-Unterstützung können implizite Quell-Builds für Build-Abhängigkeiten zulassen und gleichzeitig geeignete Maßnahmen ergreifen, um die neuen Probleme zu vermeiden, die auftreten, sobald Sie dies zulassen.
2. Das Ausgeben des relevanten python -m pip wheel X Y Z -Befehls in einer Fehlermeldung, ohne dass der Build tatsächlich implizit ausgeführt wird, ist vorerst eine angemessene Problemumgehung, da dadurch sichergestellt wird, dass Pip nicht versehentlich eine Maschine mit einer Fork-Bombe bombardieren kann.
3. Isolierte Builds sollten wahrscheinlich noch nicht der Standard sein, es sei denn , das zu erstellende Rad hat eine pyproject.toml -Datei oder isolierte Builds werden explizit von der Befehlszeile angefordert. Dies ist ein Problem mit der Abwärtskompatibilität, da bestehende Projekte das nicht isolierte Verhalten erwarten werden. Sobald isolierte Builds für ein oder zwei Releases verfügbar waren und alle Usability-Probleme mit ihnen ausgearbeitet wurden, können sie allgemein zum Standard werden (vielleicht mit einer Befehlszeilenoption, um eine bestimmte Build-Umgebung anzugeben, die verwendet werden soll, anstatt implizit isolierte Builds zu generieren Einsen)

@ncoghlan Nur um Ihnen ein Heads-up zu geben: Keine Standard-Build-Isolation bedeutet kein PEP 517 (zumindest bei meinem Ansatz), da nur die neueste Version von Setuptools dies unterstützt (wir müssen ein neueres Setuptools installieren, unabhängig davon, was sich auf der Person befindet Computer). In der Praxis denke ich, dass dies PEP 517 um mindestens ein Jahr verzögern könnte, da es den Aufwand für die Implementierung dramatisch erhöhen wird (erfordert PEP 517- und Nicht-PEP 517-Code).

Dies ist ein Problem mit der Abwärtskompatibilität, da bestehende Projekte das nicht isolierte Verhalten erwarten werden.

Die meisten Leute haben CI-Skripte, die pip install X und dann pip install Y ausführen. Diese Projekte müssten pypproject.toml hinzufügen. Aber das Hinzufügen von pyproject.toml ist nicht so viel Arbeit, und wir können bei Bedarf ein Befehlszeilen-Flag hinzufügen, um die Build-Isolierung zu deaktivieren.

Wir sollten zumindest eine Warnung ausspucken, wenn ein Projekt kein pyproject.toml in Pip 10 hat (was so aussieht, als würde es sowieso keine PEP 517-Unterstützung haben).

@xoviat "Es wäre nicht so viel Arbeit zum Anpassen" ist nicht, wie die Abwärtskompatibilität funktioniert. Wenn dies der Fall wäre, wäre pip inzwischen zu --user als Standard-Nicht-Venv-Installationsmodell gewechselt :)

Was PEP 517 betrifft, können Sie sich nicht auf PEP 517 als Paketherausgeber verlassen, ohne eine pyproject.toml -Datei hinzuzufügen, also ist es in Ordnung, wenn nur setup.py -Projekte keine PEP 517-Unterstützung erhalten standardmäßig.

Würde es Ihnen nichts ausmachen, eine Warnung auszuspucken?

Ich würde es als Problem ansehen, wenn ein Build, der derzeit gut funktioniert, anfängt, eine Warnung auszuspucken, nur weil pip aktualisiert wurde, selbst wenn sich weder das Projekt selbst noch eine seiner Abhängigkeiten geändert hat.

PEP 518 und 517 wurden bewusst so konzipiert, dass sie keine Unterbrechungen für bestehende Projekte verursachen, bei denen sich alle beteiligten Publisher weiterhin ausschließlich auf Setuptools verlassen.

Es macht Sinn, dass pip darauf abzielt, selbst für auf Setuptools basierende Projekte wieder auf einen einzigen PEP 518-Build-Pfad zu konsolidieren, aber die Zeit dafür ist, nachdem isolierte Builds ein oder zwei Releases im Wert von praktischem Nutzen gesehen haben, nicht in der ersten Version, die sie überhaupt unterstützt.

Ich hatte genau denselben Kommentar wie Donald; Mein Verständnis von diesem Thread ist, dass nur Binärdateien vorübergehend sind, da keine Zeit ist, sie für Pip 10 zu implementieren. Richtig?

Ja. Exakt.

Es ist sinnvoll, dass pip darauf abzielt, selbst für Setuptools-basierte Projekte wieder auf einen einzigen PEP 518-Build-Pfad zu konsolidieren, aber die Zeit dafür ist, nachdem isolierte Builds ein oder zwei Releases im Wert von praktischem Nutzen gesehen haben, nicht in der ersten Version unterstützt sie überhaupt.

+1

Ich denke, dass wir darauf abzielen sollten, den alten Pfad zu entfernen, wie z. B. zwei Hauptversionen. Wenn Pip landet, volle und richtige PEP 518-Unterstützung; Wir sollten die alte Build-Logik verwerfen und sie gemäß der Standardverwerfungsrichtlinie entfernen.

Ich stimme Nicks Zusammenfassung zu und...

weil es den Aufwand für die Umsetzung dramatisch erhöhen wird

Nein. Ich glaube nicht, dass die Implementierung von PEP 518 auf diese Weise irgendwelche größeren Hindernisse hat; Ich habe über https://github.com/pypa/pip/pull/4799#issuecomment -339219397 einen kurzen Kommentar darüber abgegeben, wie dies in pip implementiert werden könnte.

Wir wollen den Menschen einen sauberen Übergang von Alt zu Neu ermöglichen. Daher müssen wir die aktuelle Installationslogik von Pip 9 unverändert lassen – was im Grunde alles unterstützen würde, was wir derzeit tun, genau so, wie wir es tun.

Das Einfügen einer pyproject.toml -Datei in das Archiv würde bedeuten, dass sich das Paket für den neueren Standard entscheidet und bereit ist, die Unterstützung für das neue Verhalten zu testen – indem es die Build-Umgebung mit Isolation und reinem Binär-Build durchläuft -Abhängigkeiten (vorerst).

Nein. Ich glaube nicht, dass die Implementierung von PEP 518 auf diese Weise irgendwelche größeren Hindernisse hat;

Diskussion über PEP 517 hier. Sorry für die Verwirrung.

Wir müssten die Tests zweimal ausführen, um beide Codepfade zu überprüfen. Ah gut PEP 517 wird wahrscheinlich zurückgestellt.

Meiner Meinung nach,

1. Warnung, wenn ein Projekt kein pyproject.toml hat, klingt nach einer sehr schlechten Idee. Schließlich haben 99 % der Projekte auf PyPI derzeit kein pyproject.toml , und wir können Endbenutzer nicht mit Warnungen zuspammen, gegen die sie nichts tun können (außer das Problem dem/den Projekt(en) zu melden ) Übersehe ich etwas?
2. Ich glaube nicht, dass die Build-Isolation überhaupt in PEP 518 erwähnt wurde. Es ist ein zusätzliches Feature, das pip schon seit einiger Zeit aufnehmen wollte, aber es ist nicht an die Unterstützung von PEP 518 gebunden, außer durch die zufällige Tatsache, dass dasselbe PR implementiert wurde beide (AFAIR). Wenn uns hier also die Build-Isolation Probleme bereitet, bin ich damit einverstanden, zunächst nur PEP 518 zu haben und in Phase 2 Isolation hinzuzufügen. Ich überlasse diese Entscheidung jedoch den Leuten, die Dinge implementieren.

Übersehe ich etwas?

NÖ.

Ich bin damit einverstanden, dass ich anfangs nur PEP 518 habe und die Isolation als Phase 2 hinzufüge.

Ich denke, wir sollten PEP 518 machen und zusammen Isolation bauen, da es eine nette Art ist, Leute dazu zu bringen, auf isolierte Builds umzusteigen.

Während weder PEP 518 noch PEP 517 isolierte Builds erfordern , empfiehlt PEP 517 sie aus guten Gründen: https://www.python.org/dev/peps/pep-0517/#recommendations -for-build-frontends-non-normative

Ohne einen lokalen binären Artefakt-Cache sind isolierte Build-Umgebungen unpraktisch, aber sobald Sie eine davon haben (wie es pip jetzt tut), sind sie weitaus praktikabler, da:

1. Bei den meisten Installationen müssen Sie nicht einmal einen Quellcode erstellen
2. Wenn Sie einen Quell-Build durchführen müssen, richten Sie normalerweise die Build -Umgebung aus dem Cache ein

Gleichzeitig erfordern isolierte Build-Umgebungen etwas mehr Arbeit von Publishern, da sie bedeuten, dass fehlerhafte Metadaten die eigenen Builds des Publishers auf eine Weise beschädigen, die es erfordert, dass sie ausdrücklich sagen: „Meine Build-Abhängigkeiten sind nicht vollständig deklariert“, um dies zu tun einen aufbau machen.

Die Isolierung von auf pyproject.toml basierenden Builds von Anfang an bietet also einen natürlichen Umschaltpunkt, da es bei diesem gesamten PEP darum geht, eine Möglichkeit bereitzustellen, Build-Abhängigkeiten klar und konsistent getrennt von Laufzeitabhängigkeiten zu deklarieren. Das bedeutet, dass Leute, die von setup.py wechseln, dies vermutlich tun, weil sie sich um solche Dinge kümmern, während Leute, die frisch für neue Projekte dazu kommen, es nur als einen weiteren Reifen behandeln werden, den die Verpackungswerkzeuge sie zwingen, zu springen durch.

Also, nur ein paar Dinge, die ich bestätigen möchte, bevor ich mit dem Schreiben von Code beginne:

• PEP 517-Unterstützung ist kein Blocker für Pip 10
• PEP 518 in Pip 10
  
  
  
  • Anmeldung über pyproject.toml
  
  
  • unterstützt nur binäre Build-Abhängigkeiten
  
  
  • isolierte Bauten
  
  

PEP 517 kann kein Blocker für Pip 10 sein, da es noch nicht fertig ist und es an diesem Punkt keinen klaren Weg nach vorne gibt (es gibt einen Weg nach vorne, aber er ist nicht klar).

Ich habe einen Kommentar und eine Frage als Antwort auf den Kommentar von @xoviat hier , der die Implementierungsherausforderungen zusammenfasst, sowie nachdem ich diesen Thread schnell gelesen habe.

Erstens, in Bezug auf das Problem der Rekursion, dass Dinge möglicherweise explodieren, kann im Allgemeinen jede rekursive Funktion in eine iterative "übersetzt" werden. Ich frage mich, ob dieser Ansatz hier helfen könnte, indem er mehr Kontrolle bietet.

Zweitens, was kostet das Berappen im Gegensatz zum Aufrufen einer Pip-Funktion aus Python heraus? Gibt es einen Grund, warum eine interne API-Funktion nicht erstellt / umgestaltet werden konnte, die alles tun würde, was Beschuss zu erreichen versucht? Das sollte mehr Flexibilität beim Aufrufen des Anrufs bieten (im Vergleich zu CLI-Parametern). Dies könnte auch mehr Kontrolle bieten, indem es einem ermöglicht wird, den Zustand des Gesamtprozesses leichter zu verwalten.

Gibt es einen Grund, warum eine interne API-Funktion nicht erstellt / umgestaltet werden konnte, die alles tun würde, was Beschuss zu erreichen versucht?

Zweitens, was kostet das Berappen im Gegensatz zum Aufrufen einer Pip-Funktion aus Python heraus?

Es kauft Zeit, die wir derzeit nicht haben. pip ist bereits hinter seinem Veröffentlichungszeitplan zurück.

Erstens, in Bezug auf das Problem der Rekursion, dass Dinge möglicherweise explodieren, kann im Allgemeinen jede rekursive Funktion in eine iterative "übersetzt" werden.

Ich bin nicht gegen Rekursion. Ich bin gegen Prozessrekursion. Ich denke, es ist in Ordnung, wenn Sie 100% CPU verwenden möchten (naja, in Python wären es 20%), aber letztendlich muss der Benutzer in der Lage sein, den Task-Manager zu öffnen und die maximal 15 vorhandenen Prozesse zu beenden. Für mich ist eine Situation, die möglicherweise eine Prozessexplosion verursachen könnte, inakzeptabel.

Das beantwortet jedoch nicht die Frage, warum es Zeit kauft. Was macht es schwierig, eine interne API-Funktion zu erstellen, die dasselbe tut?

In jedem Fall, wenn das Ausschalen ein bestimmtes Problem löst, könnte eine Möglichkeit, diesen Ansatz zu vereinfachen, darin bestehen, vorübergehend einen privaten / internen CLI-Befehl bereitzustellen, der es einfacher macht, alle erforderlichen Informationen zu übergeben (z. B. könnte es sogar ein serialisiertes Python-Objekt sein). , etc).

Das beantwortet jedoch nicht die Frage, warum es Zeit kauft. Was macht es schwierig, eine interne API-Funktion zu erstellen, die dasselbe tut?

Wenn Sie denken, dass es einfach ist, dann machen Sie weiter. Ich sage das nicht sarkastisch: Bitte machen Sie weiter, denn es wird alle Probleme lösen.

Ich glaube nicht, dass es einfach ist. Ich stelle die Frage, um einen Einblick zu bekommen, warum es schwer ist. (Ich nehme an, Sie haben darüber nachgedacht, da Sie sagten, es würde Zeit sparen.)

Sie benötigen separate Pip-Installationen, um im Allgemeinen innerhalb eines Unterprozesses ausgeführt zu werden, da es Caches an Orten wie pkg_resources gibt, glaube ich (obwohl ich mich dort irren könnte).

Das bedeutet jedoch nicht, dass Sie pip aufrufen müssen, Sie können eine API erstellen, die Daten über die CLI serialisiert und python -c "from pip._internals import coolapithing; coolapithing(sys.stdin.read())" aufruft und mehr Daten von stdout liest. Es wäre möglich, die rekursive Lösung von Pips Aufrufen von Pips Aufrufen von Pips Aufrufen von Pips umzuwandeln, indem Sie sie mithilfe einer solchen API in einen Stack umwandeln (da alle Rekursionen auch als Stack beschrieben werden können), würden Sie im Wesentlichen nur eine private API erstellen das wird als Prozess aufgerufen.

Ich plane immer noch, diesen Thread zu lesen (hatte in letzter Zeit eine Menge Platten im Umlauf!), aber eins zur Sache: Wir haben keinen wirklichen Veröffentlichungszeitplan, wir veröffentlichen, wenn es fertig ist, nicht an einem bestimmten Datum. Manchmal haben wir eine ungefähre Vorstellung davon, wann wir veröffentlichen möchten, aber das ist nie in Stein gemeißelt.

Letztendlich hat Python jedoch eine maximale Rekursionstiefe, um sicherzustellen, dass die Dinge nicht außer Kontrolle geraten. Wir müssten das implementieren, wenn wir diesen Ansatz verfolgen würden.

Ja, ein Stack-basierter Ansatz macht es ziemlich effizient, ziemlich tief zu gehen (viel tiefer als alles andere als eine Abhängigkeitsschleife jemals tun würde, zum Beispiel könnten wir etwas haben, das buchstäblich von jedem Paket abhängt und trotzdem in Ordnung ist), die Hauptsache zu tun ist, Schleifen zu erkennen.

Eine ziemlich naive und einfache Methode zur Schleifenerkennung besteht darin, einfach eine Obergrenze für die Anzahl der Elemente auf dem Stapel festzulegen und zu sagen, dass Sie sich, wenn Sie diese Grenze erreichen, sicherlich in einer Schleifensituation befinden und einen Fehler ausgeben müssen. Die Nachteile dabei sind natürlich, dass Schleifen nicht so früh wie möglich erkannt werden und Pakete mit tieferen Bauabhängigkeitsketten als das Limit einfach nicht funktionieren.

Die im Allgemeinen bessere Option (da Sie bei einem Stack-basierten Ansatz auf den gesamten Stack zugreifen können) besteht darin, einfach den Stack zu durchlaufen und nachzusehen, ob sich das Element, das wir installieren möchten, bereits irgendwo auf dem Stack befindet und ob dies der Fall ist Breakout und Fehler, weil wir auf eine Schleife gestoßen sind (dieser Fehler könnte entweder dem Endbenutzer präsentiert werden, oder könnte schließlich zum Resolver sprudeln, um eine andere Version auszuprobieren – obwohl das ihn viel, viel langsamer macht).

Und um die Frage von @cjerdonek direkt zu beantworten: Im Prinzip ist das nicht schwer, was die Dinge schwierig macht, sind einige eingebettete architektonische Annahmen in der Art und Weise, wie pip derzeit funktioniert, die in einer Welt, in der jede Quelle erstellt wird, nicht mehr zutreffen erhält seine eigene isolierte Build-Umgebung, anstatt nur direkt in der Installationsumgebung ausgeführt zu werden.

Das bedeutet, dass der einfachste Weg, die vorhandene Abhängigkeitsverwaltungslogik von pip wiederzuverwenden, ohne über diese internen architektonischen Einschränkungen zu stolpern und ohne das Risiko einzugehen, aktuell funktionierenden Code zu brechen, darin besteht, eine weitere Instanz von pip in einem Unterprozess auszuführen. Das ist größtenteils in Ordnung, mit Ausnahme der Konsequenz, dass das Versäumnis, Abhängigkeitsschleifen zu erkennen und zu verlassen, das System, auf dem der Build ausgeführt wird, mit einer Gabel bombardieren kann.

Ich mag die Idee von @dstufft , in einen iterativen / stapelbasierten Ansatz umzuwandeln und mit dem Muster python -c "from pip._internals import coolapithing; coolapithing(sys.stdin.read())" in eine interne Pip-Funktion umzuwandeln. Das scheint aufgrund der Diskussion am einfachsten und robust zu sein.

Ich denke, der erste Schritt in diese Richtung wäre, den einfachen rekursiven Ansatz auf eine einzige rekursive Python-Funktion mit der erwarteten Ein- und Ausgabe zu reduzieren (zumindest skizzieren), und dies könnte dann in den iterativen Ansatz übersetzt / konvertiert werden. Und ja, Sie könnten set an besuchten Anrufen verwalten, um Schleifen zu vermeiden, was einer der einfacher zu lösenden Aspekte zu sein scheint.

Ich habe ein wenig mehr darüber nachgedacht, den rekursiven Ansatz in einen iterativen umzuwandeln. Die teilweise Arbeit von @xoviat an PEP 518 (PR #4799) hat mir geholfen, den Rekursionspunkt zu finden (mit dem einige von Ihnen wahrscheinlich bereits vertraut sind). Es ist in seinem Code-Kommentar:

# TODO: Use single process with recursion handling

wo es dann pip install ... aufruft.

Meine Idee ist, dass es so aussieht, als könnte dies vielleicht durch eine Variante von pip install (für die Build-Abhängigkeiten) mit etwa der folgenden Änderung gelöst werden:

• Wenn die Installation keine Unterinstallationen erfordert, führen Sie die Installation durch.
• Andernfalls kehren Sie mit einer (möglicherweise unvollständigen) Liste der erforderlichen Unterinstallationen zurück (z. B. indem Sie die Informationen in eine vereinbarte Datei schreiben, wenn das Schreiben in stdout nicht bereits funktioniert).

Auf diese Weise kann der Root-Prozess der obersten Ebene nach und nach einen Baum der Build-Abhängigkeiten generieren. Und es kann Blätter so verarbeiten, wie sie gefunden werden. Wenn Blätter verarbeitet werden, werden Knoten, die vorher keine Blätter waren, zu Blättern und so weiter. Bei dieser Implementierung findet zu jedem Zeitpunkt nur höchstens eine Pip-Installation in einem Unterprozess statt.

Eine kleine Variation zu dem, was ich oben vorgeschlagen habe, ist, dass der erforderliche Pip-Befehl / Unterprozessaufruf eine Liste der Unterinstallationsaufrufe zurückgeben / ausgeben kann, die eine Kandidateninstallation erfordern würde (ein pip get-subinstalls oder einfach pip subinstalls Befehl). Der einzige Unterschied zu dem, was ich oben vorgeschlagen habe, besteht darin, dass dieser Befehl auf das Melden von Informationen beschränkt wäre. Es würde nicht wirklich die Installation tun. Die Implementierung könnte also einfacher / einfacher zu testen sein.

@cjerdonek Ich sehe kein Problem mit dieser Idee. Aber letztendlich muss es jemand implementieren (ich glaube, @pradyunsg wollte an diesem Wochenende an etwas arbeiten?) Und wie immer können dann weitere Schwierigkeiten entdeckt werden.

Es hat sich etwas ergeben. Wenn jemand anderes das abholen möchte, ich habe keine
Probleme. :)

Ich mag auch die Idee von @dstufft .

Am Sonntag, 29. Oktober 2017, 08:47 xoviat, [email protected] schrieb:

@cjerdonek https://github.com/cjerdonek Ich sehe kein Problem mit
diese Idee. Aber letztendlich muss es jemand umsetzen (glaube ich
@pradyunsg https://github.com/pradyunsg wollte an etwas arbeiten
dieses Wochenende?) und wie immer können dann weitere Schwierigkeiten entdeckt werden.

—
Sie erhalten dies, weil Sie erwähnt wurden.

Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/pypa/pip/issues/4802#issuecomment-340234567 , oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/ADH7SYImpWgJGg-DzQRcO_9hHfE6ZxEAks5sw-5RgaJpZM4QBdSg
.

Um darauf zurückzukommen, wollen wir mit dem von @dstufft vorgeschlagenen Stack + internen Aufruf fortfahren?

/ping @ncoghlan @pfmoore @xavfernandez

Ja bitte. Alles, um dies voranzutreiben.

Gibt es jemanden, der zusammenfassen kann, wo wir mit PEP 517 und PEP 518 in Bezug auf eine Veröffentlichung von Pip 10 stehen? Speziell:

1. Befindet sich der Master derzeit in einem freigabefähigen Zustand? Zuletzt habe ich gehört, dass die PEP 518-Unterstützung unterbrochen wurde (es gibt mindestens ein offenes Release-Blocker-Problem im Zusammenhang mit PEP 518 – #4647).
2. Werden wir wahrscheinlich eine funktionierende PEP 517- und/oder PEP 518-Implementierung in einem Zeitrahmen haben, der es vernünftig macht, Pip 10 zu verzögern, bis sie verfügbar sind?
3. Angenommen, wir reparieren das Zeug in (1), wollen wir eine Pip 10-Veröffentlichung ohne PEP 517/518 machen? Wir haben eine Heads-up-E-Mail über die Veröffentlichung erstellt, damit die Leute wissen, dass sie kommt. Und es gibt einige einigermaßen wichtige Fixes darin (z. B. Codierungsfixes für Windows), die gerne veröffentlicht würden.

Mein Gefühl ist, dass wir auf die Release-Blocker warten, aber wir sind nicht nah genug an der PEP 517/518-Unterstützung, um Pip 10 auf ihnen zu blockieren. Aber ich glaube nicht, dass irgendjemand an #4647 arbeitet, außer als Teil der Implementierung von PEP 518.

Eine alternative Option wäre, die Einschränkungen der aktuellen PEP 518-Unterstützung zu dokumentieren und #4647 als Release-Blocker herabzustufen. Ich weiß nicht genug über die Anwendungsfälle, um zu wissen, ob das praktikabel ist.

Ich habe diese Diskussion gerade erst gesehen – Entschuldigung für die unausgegorene anfängliche Implementierung, die wahrscheinlich wie eine Fork-Bombe wirkt, und danke an alle, die sich die Zeit genommen haben, sie zu verstehen und bessere Ideen zu entwickeln.

FWIW, ich denke, es wäre ein akzeptabler Kompromiss für die erste Version, es auf den Einbau von Rädern für Bauanforderungen zu beschränken.

Dies erinnert mich auch daran, dass ich die Dinge wahrscheinlich so beheben sollte, dass Flit keine Build-Anforderung an sich ist.

Entschuldigung für die unausgegorene anfängliche Implementierung, die wahrscheinlich wie eine Gabelbombe wirkt,

Keine Entschuldigung nötig. Wie gesagt, Sie können diese Probleme nicht beim ersten Versuch vorhersagen. Selbst wenn wir wissen, was wir jetzt wissen, hätte eine Verzögerung der PR diese Diskussionen nur verschoben.

Befindet sich der Master derzeit in einem freigabefähigen Zustand?

IIUC, es kann ab sofort ein System mit einer Gabelbombe bombardieren; Ist das korrekt? Wenn ja, denke ich, ist es nicht.

Werden wir wahrscheinlich eine funktionierende PEP 517- und/oder PEP 518-Implementierung in einem Zeitrahmen haben, der es vernünftig macht, Pip 10 zu verzögern, bis sie verfügbar sind?

Ich denke, die einfache (kurzfristige) Lösung wäre, sich nur auf Räder für Build-Abhängigkeiten zu beschränken. Ich werde versuchen, es irgendwann nächste Woche zu versuchen. Wenn das nicht zustande kommt, ist es mir recht, wenn wir die aktuelle PEP 518-Unterstützung aus dem Master entfernen und daraus eine 10.0.0 herausschneiden.

Ich glaube nicht, dass irgendjemand an #4647 arbeitet, außer als Teil der Implementierung von PEP 518.

Ich denke, Sie meinen, vollständige Implementierung von PEP 518 mit zulässigen Source-Build-Abhängigkeiten?

Oh, und zu #4647 -- die obige Beschreibung von @xoviat besagt, dass eine Behebung das Ändern/Verschieben von Code und Besitz/Sichtbarkeit von Objekten (insbesondere BuildEnvironment ) erfordern würde, was nicht trivial ist.

Ich denke, dass es so einfach sein sollte, es auf Räder zu beschränken, wie diese Zeile zu ändern:

https://github.com/pypa/pip/blob/fc6b2c192088737f81259b6446f627f20ce46443/src/pip/_internal/wheel.py#L696

zu:

finder.format_control = FormatControl(set(), set([':all:']))

Das zweite Feld enthält eine Reihe von Paketen, die nur als Binärdateien zu finden sind, mit einem Sonderfall für ':all:' , um alle Pakete zu bedeuten.

Ja. Aber das allein würde #4647 nicht ansprechen. Außerdem geht keiner dieser Codes
durch einen Resolver.

Am Sa, 2. Dez. 2017 um 01:23 schrieb Thomas Kluyver [email protected] :

Ich denke, dass es so einfach sein sollte, es auf Räder zu beschränken, wie dies zu ändern
Linie:

https://github.com/pypa/pip/blob/fc6b2c192088737f81259b6446f627f20ce46443/src/pip/_internal/wheel.py#L696

zu:

finder.format_control = FormatControl(set(), set([':all:']))

Im zweiten Feld gibt es eine Reihe von Paketen, die nur als Binärdateien zu finden sind
ein Sonderfall für ':all:', um alle Pakete zu bezeichnen.

—
Sie erhalten dies, weil Sie erwähnt wurden.

Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/pypa/pip/issues/4802#issuecomment-348598368 , oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/ADH7SUi0QMS3rr5Iba90XWZmFweGmqeBks5s8FlEgaJpZM4QBdSg
.

Richtig, da ist noch ein Haufen anderer Sachen falsch. Aber das sollte Fork-Bombing verhindern, was meiner Meinung nach die dringendste Sorge ist.

Wenn jemand meine ursprüngliche PR übernehmen möchte ("PEP 518-Probleme beheben"),
Es sollte nicht zu schwierig sein, es so zu ändern, dass die Build-Isolation dies nicht ist
ohne pyproject.toml aktiviert. Der ursprüngliche Grund, warum es nicht zusammengeführt wurde
war, dass die Unterstützung für die Installation von Abhängigkeiten aus der Quelle mit eingestellt wurde
PEP 518. Aber jetzt, da die Leute anfangen zu erkennen, dass PEP 518 möglicherweise
überhaupt nicht in Pip 10 sein, sind sie möglicherweise eher bereit, diese PR zu akzeptieren. ich
Ich persönlich habe keine Zeit, mich dafür einzusetzen, aber das sollte andere nicht davon abhalten
davon abhalten, es voranzutreiben, da nur wenige Zeilen Änderungen erforderlich sind
(abgesehen vom Nichtbestehen des PEP 518-Tests).

Eigentlich bin ich wider besseres Wissen bereit, sowohl PEP 517 als auch 518 in Kürze zu implementieren, wenn die Pip-Entwickler meinen Bedingungen zustimmen:

1. Abhängigkeiten bestehen zunächst nur von Rädern
2. pip wird zunächst ein internes Build-Backend haben, auch wenn es irgendwann entfernt wird

Ich habe keine Probleme mit 1; Für 2 habe ich keine Präferenz.

Am Sonntag, den 3. Dezember 2017 um 02:36 Uhr schrieb xoviat [email protected] :

Eigentlich bin ich wider besseres Wissen bereit, beide PEP umzusetzen
517 und 518 in Kürze, wenn die Pip-Entwickler meinen Bedingungen zustimmen:

1. Abhängigkeiten bestehen zunächst nur von Rädern
2. pip wird zunächst ein internes Build-Backend haben, obwohl es
   wird schließlich entfernt

—
Sie erhalten dies, weil Sie erwähnt wurden.

Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/pypa/pip/issues/4802#issuecomment-348720096 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/ADH7ST6riptZkYMap5Z5SstRf-VmE7eAks5s8bu5gaJpZM4QBdSg
.

Zu Ihrer Information, die Bedingungen sind nicht willkürlich, sondern dazu da, eine anfängliche Implementierung zu ermöglichen. Ist @pfmoore damit einverstanden?

Ich fühle mich nicht besonders wohl mit dem Ton des Angebots "Wider besseres Wissen ... stimme meinen Bedingungen zu". Ich werde nichts dagegen haben, wenn die anderen Pip-Entwickler dieses Angebot gerne annehmen, aber ich persönlich habe im Moment nicht die Zeit, die ganze Debatte über Implementierungsdetails neu zu starten. Grundsätzlich verlasse ich mich dabei auf @dstufft und @xavfernandez ( @pradyunsg hat bereits seine Meinung geäußert).

Der Ton des Angebots ist so, weil Wege der Umsetzung aufgrund grundlegender Meinungsverschiedenheiten darüber, wie eine erste Umsetzung aussehen würde, verschlossen wurden. Ich würde mich jetzt lieber auf die Prinzipien einigen, als mich in eine weitere Umsetzungsdebatte zu vertiefen.

Ich sage nur, dass ich mich mit dem Ton auch nicht besonders wohl fühle, das ist es
Nur habe ich weder die Zeit noch die Energie, darauf einzugehen, warum dieser Ton verwendet wurde
usw. Derselbe Grund für die knappe Antwort von meiner Seite.

Vielleicht auch erwähnenswert, ich bin cool mit nur binären Build -Abhängigkeiten
die erste Implementierung, nicht über einen längeren Zeitraum. Dies gilt nicht für
Laufzeitabhängigkeiten (da das auch irgendwie in einer anderen aufgetaucht ist
Diskussion).

Am Sonntag, 3. Dezember 2017, 23:37 Uhr xoviat, [email protected] schrieb:

Der Ton des Angebots ist so, wie es da ist
Umsetzung aufgrund grundlegender Meinungsverschiedenheiten über das, was abgeschlossen wurde
wie eine erste Implementierung aussehen würde. Dem stimme ich lieber zu
Prinzipien jetzt in eine weitere Umsetzungsdebatte übergehen.

—
Sie erhalten dies, weil Sie erwähnt wurden.

Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/pypa/pip/issues/4802#issuecomment-348802032 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/ADH7ScUh-BveonoTxZ5FkkeSynFvoLb8ks5s8uNRgaJpZM4QBdSg
.

Ehrlich gesagt ist es wahrscheinlich keine effektive Nutzung der Zeit von irgendjemandem, den Ton des Beitrags weiter zu diskutieren, da es für die Aufnahme dieser Funktionen in Pip 10 nicht relevant ist. Ich brauche jedoch die Zusicherung, dass meine Bedingungen akzeptabel sind, um von beiden @pfmoore ( der angegeben hat, dass er eine solche Versicherung nicht abgeben kann, was akzeptabel ist, da niemand für seine Zeit hier bezahlt wird), @dstufft oder @xavfernandez.

Auch hier sind die Konditionen nicht meine persönliche Meinung, sondern umsetzungsgetrieben. Wenn ich diese Bedingungen lockere, kann ich keine Implementierung versprechen, also macht es keinen Sinn, Zeit mit der Vorbereitung einer PR zu verbringen, und dann lesen die Leute das Diff und fragen: "Oh, warum ist diese Zeile hier?" und dann "oh, das ist also nicht zusammenführbar?" weil es ein Missverständnis darüber gab, was genau der Zweck der PR war.

Stimme dem Ton zu. Mein Punkt ist einfach, dass ich die Änderung nicht zusammenführen werde[1], daher ist meine Ansicht hier nicht wirklich so wichtig.

[1] Natürlich sage ich das, ohne die Implementierung gesehen zu haben, also hoffe ich, dass klar ist, dass meine Gründe nicht mit Bedenken hinsichtlich der Codequalität zu tun haben – es geht darum, dass ich nicht die Zeit habe, sicherzustellen, dass ich den Code gut genug verstehe bereit sein, im Grunde zu fusionieren.

@xoviat Was sind Ihre Implementierungspläne in Bezug auf den iterativen vs. rekursiven Ansatz, den wir oben besprochen haben?

Sagen Sie zur Klarstellung auch, dass Sie zuerst eine teilweise Implementierung von PEP 517 und 518 abschließen werden, die zusammengeführt werden kann, gefolgt von einer vollständigen Implementierung, die zusammengeführt werden kann? Oder sagen Sie, dass Sie nur die teilweise Implementierung durchführen werden, oder sagen Sie, dass Sie eine vollständige Implementierung durchführen werden, die frühere Phasen durchläuft, die nicht unbedingt zusammengeführt werden können? (Ich versuche teilweise, ein besseres Gefühl dafür zu bekommen, was Sie in Ihrem Kommentar mit "anfänglich" und "schließlich" meinen.)

Die erste Bedingung eliminiert das gesamte Rekursionsproblem.

Sagen Sie zur Klarstellung auch, dass Sie zuerst eine teilweise Implementierung von PEP 517 und 518 abschließen werden, die zusammengeführt werden kann, gefolgt von einer vollständigen Implementierung, die zusammengeführt werden kann?

Was ich sage ist, dass ich eine Teilimplementierung abschließen werde, die für 95 % der Anwendungsfälle funktionieren wird; insbesondere in dem Fall, in dem Abhängigkeiten Räder haben (heute sehr verbreitet) und Sie sich auf einer Manylinux/Windows/OSX-Plattform befinden (die überwiegende Mehrheit der Benutzer).

Es ist keine vollständige Implementierung. Aber die Art und Weise, wie Sie nicht zusammenführbare PRs erhalten, ist der Versuch, den „Alles-oder-Nichts“-Ansatz zu verfolgen, bei dem Sie entweder den Standard einhalten oder nicht.

Denken Sie daran, dass eine vollständige Implementierung das Sortieren einiger ziemlich unangenehmer Probleme erfordert, die jeweils eine separate PR erfordern (da eine PR mit mehr als 100 Kommentaren normalerweise bedeutet, dass der Code nicht gut überprüft ist). [1]

[1] https://github.com/btc1/bitcoin/pull/11#issuecomment -313843216

Ich werde dieses Problem jetzt schließen – wir haben vorläufige Unterstützung für PEP 518 in Pip 10, das nur Räder als Build-Abhängigkeiten unterstützt. Ich werde ein neues Thema eröffnen, um über die vollständige Unterstützung zu diskutieren, und ein weiteres für die Unterstützung von PEP 517 (wobei von hier zitiert wird, wenn relevant).

Danke @ncoghlan @rgommers @cjerdonek für deine Einblicke und Hilfe hier. Danke @takluyver für die anfängliche Implementierung von PEP 518. Danke @xoviat (der jetzt @ghost ist) für all die Hilfe bei der Implementierung dieser Änderungen. Danke @benoit-pierre für deine Hilfe bei der Verbesserung des aktuellen Supports.

PS: 100. Kommentar! :tada:

Dieser Thread wurde automatisch gesperrt, da es nach seiner Schließung keine Aktivitäten mehr gegeben hat. Bitte öffnen Sie ein neues Problem für verwandte Fehler.