Pip: Fehler bei `import pip` in pip 9.0.2

Auch das kann ich bestätigen. Bin gerade dabei, das gleiche Problem zu melden.

Dies ist ein Dupe von #5079 – das Importieren von Pip ist kein unterstützter Anwendungsfall (und war es nie).

Komm schon.. eine große bahnbrechende Änderung in einem einzigen x.x.PATCH Versionsstoß vornehmen? Für eine Top-Level-Methode namens "main"? Ich denke, das ist eine ziemlich schlechte Form..

Dies brach auch Anaconda und ich kam auf die gleiche Lösung wie @Miserlou :

https://github.com/ContinuumIO/anaconda-issues/issues/8911

Fehler werden in vielen Projekten gemeldet.

Dieser Fehler hat mich auch gestört, als ich versucht habe, mit pip meinen Anaconda-Navigator zu aktualisieren.

Besteht die Chance, dass wir eine Version 9.0.3 bekommen, die das behebt – idealerweise schon bald?

Dies betrifft bereits viele große Projekte (Anaconda, SpaCy, Zappa), und es gibt mehr als 850.000 Anwendungen davon allein auf GitHub , die jetzt durch dieses angebliche „Patch“-Versionsupdate kaputt sind.

Können Sie diese massive Änderung in 9.0.3 zumindest rückgängig machen und dann den Downstreams Ihre Absicht mitteilen, dieses Verhalten für eine zukünftige 10.xx- oder mindestens 9.xx-Version zu ändern?

Wir wollen auch keine ältere Version verwenden, aber genau das haben wir schließlich getan. 9.0.2 existiert zumindest vorerst nicht in unserer CI-Umgebung.

Sehen Sie diesen Hit auch in einigen OpenStack-Projekten.

Pip 10 soll in etwa einem Monat erscheinen. So wie ich es verstehe, liegt das Problem bei Code, der import pip verwendet, um auf die interne Funktionalität von Pip zuzugreifen. Wir haben eine solche Verwendung nie offiziell unterstützt, und wir haben diesen Mangel an Unterstützung seit einiger Zeit explizit dokumentiert (wenn auch nur in der „neuesten“ Version der Dokumentation unter https://pip.pypa.io/en/latest/user_guide /#using-pip-from-your-program, weil wir keine neue stabile Version hatten, seit dieser Doc-Abschnitt hinzugefügt wurde). Wir haben letzten Oktober auch eine Neuorganisation der Interna angekündigt, um klarzustellen, dass die Verwendung interner APIs nicht unterstützt wird (siehe https://mail.python.org/pipermail/distutils-sig/2017-October/031642.html). Diese Änderung, die sich in Pip 10 befindet, wird jede solche Verwendung unterbrechen, unabhängig davon, was eine mögliche Version von Pip 9.0.3 tun würde. Es ist also schwer, dies als plötzlichen, unerwarteten Bruch zu sehen.

Wenn @dstufft eine Notfallversion von 9.0.3 machen möchte, bin ich damit einverstanden. Aber es wird nur ein sehr kurzfristiger Vorteil sein, und ich bin ein wenig enttäuscht, dass die Leute noch nicht von import pip abgerückt sind. Die von diesem Problem betroffenen Personen müssen sich immer noch auf Pip 10 vorbereiten und sollten verstehen, dass wir den einfachen Wechsel zu import pip._internal nicht unterstützen oder empfehlen werden.

Vorschläge zur Wiedereinführung eines gewissen API-Supports sind sicherlich eine Option (siehe zum Beispiel #5080), aber in diesem Stadium ist es für solche Änderungen zu spät, um es in Pip 10 zu schaffen.

Da der Code für diejenigen, die den alten Weg verwenden, keine Warnungen ausgibt, nichts dies als "intern" bezeichnet und mit _ beginnt, und dies nur ein Bugfix-Bump ist, denke ich, dass es eigentlich ziemlich einfach ist, dies als plötzlichen, unerwarteten Bruch zu sehen .

Ja, das ist die Art von Änderung, die man von einem MAJOR Versionsupdate erwarten kann. Das wäre schön.

Leider kam diese gewaltige Änderung mit einem PATCH Update, das _angeblich Dinge reparieren, nicht kaputt machen_ soll. Dies ist das genaue Gegenteil von semantischer Versionierung. Und als Ergebnis sehen wir massive Schäden im gesamten Python-Ökosystem.

Sie sollten diese Änderung so schnell wie möglich in einem weiteren PATCH -Update rückgängig machen und dann die wichtigsten bahnbrechenden Änderungen mit dem MAJOR -Versionsupdate bereitstellen. Jetzt, wo Sie bereits alles für alle vorzeitig kaputt gemacht haben, werden sie sich meiner Meinung nach mehr bewusst sein, dass die eigentliche große Änderung bevorsteht.

Ich denke auch, dass es ein Bulle ist, zu sagen, dass dies bereits dokumentiert und angekündigt wurde, wenn man bedenkt, dass es _nicht_ in der Stable -Dokumentation dokumentiert war und dass die Ankündigung besagte, dass die Unterbrechung _für die Hauptversion_ erfolgen würde, nicht für einen Patch in einem Monat frühere.

Bitte, ersparen Sie allen einfach massive Kopfschmerzen, machen Sie dieses Problem rückgängig und fangen Sie an, sich tatsächlich an die semantische Versionierung zu halten.

@Miserlou OK, ich verstehe Ihren Standpunkt - wir haben die interne Umbenennungsänderung für Pip 10 ins Visier genommen, weil es sich um eine Hauptversion handelt. Ich kenne die Treiber für die Patch-Veröffentlichung nicht wirklich - @dstufft hat mich darüber angepingt, und es dient anscheinend dazu, erhebliche Brüche für Mac OS-Benutzer zu vermeiden, wenn eine bevorstehende Frist für die TLS-Unterstützung auf uns zukommt, die vor der Veröffentlichung von Pip 10 liegt. Wir haben erwartet, dass die Probleme erheblich genug sind, um eine kurzfristige Patch-Veröffentlichung zu rechtfertigen. Es bestand sicherlich keine Absicht, die bestehende Nutzung zu brechen.

Ich muss @dstufft die Entscheidung über ein Follow-up 9.0.3 überlassen - ich habe keine Details darüber, was in 9.0.2 eingeflossen ist, oder weiß, ob es überhaupt möglich ist, herauszufinden, wie dieses Problem behoben werden kann. Und ich kann nicht beurteilen, ob das Entfernen von 9.0.2 insgesamt ein Vorteil sein wird, da ich keine Ahnung habe, wie viele Menschen von dem Mac OS-Problem betroffen sind. Ich verstehe, dass (zumindest für einige Leute) das Anheften an 9.0.1 eine Lösung ist, sodass dies möglicherweise die am wenigsten schlechte Option ist.

Das macOS-TLS-Problem betrifft jeden, der ein System-Python auf macOS<10.13 verwendet

Die Entscheidung eines Nachfolgers 9.0.3 muss ich @dstufft überlassen

Ich bin in der gleichen Position wie @pfmoore.

Problemumgehung, wenn Sie es zur Verfügung haben, besteht darin, die Reihenfolge der Importe zu überprüfen und zu testen, wie Sie das Importieren von Pip über andere Paketimporte verschieben (insbesondere das Importieren von Pip _vor_ dem Importieren von Anforderungen scheint einige Fälle zu lösen). (Beachten Sie, dass dies immer noch die Verwendung von Pips Interna impliziert, die nicht offiziell unterstützt werden.)

Dasselbe Problem hier mit Pip 9.0.2 in einem Gitlab-ci mit Docker Python 3.4: KeyError

  File "/usr/local/lib/python3.4/site-packages/pip/__init__.py", line 45, in <module>
    from pip.vcs import git, mercurial, subversion, bazaar  # noqa
  File "/usr/local/lib/python3.4/site-packages/pip/vcs/mercurial.py", line 9, in <module>
    from pip.download import path_to_url
  File "/usr/local/lib/python3.4/site-packages/pip/download.py", line 40, in <module>
    from pip._vendor import requests, six
  File "/usr/local/lib/python3.4/site-packages/pip/_vendor/requests/__init__.py", line 98, in <module>
    from . import packages
  File "/usr/local/lib/python3.4/site-packages/pip/_vendor/requests/packages.py", line 12, in <module>
    sys.modules['pip._vendor.requests.packages.' + mod] = sys.modules["pip._vendor." + mod]
KeyError: 'pip._vendor.urllib3.contrib'

FYI, 9.0.2 wurde mit defekten Builds veröffentlicht:

Travis-CI-Referenz: https://travis-ci.org/pypa/pip/builds/354616774?utm_source=github_status&utm_medium=notification

Zugegeben, die Fehler stehen möglicherweise in keinem Zusammenhang, obwohl dies nur nach einer "überstürzten Veröffentlichung" riecht ...

@pfmoore

Wenn @dstufft eine Notfallversion von 9.0.3 machen möchte, bin ich damit einverstanden. Aber es wird nur ein sehr kurzfristiger Vorteil sein, und ich bin ein wenig enttäuscht, dass die Leute sich nicht bereits von Import Pip entfernt haben. Die von diesem Problem betroffenen Personen müssen sich immer noch auf Pip 10 vorbereiten und sollten verstehen, dass wir den einfachen Wechsel zum Import von pip._internal nicht unterstützen oder empfehlen.

Ich kann nicht glauben, dass dies eine Aussage des Eigentümers dieses Repositorys ist ... Sie haben buchstäblich nur "f * ck semantische Versionierung" und "wer braucht überhaupt eine Verfallsrichtlinie" gesagt.

pip war immer dokumentiert, dass es KEINE verbrauchbare Python-API hatte, ich bin enttäuscht von Leuten, die sogar zu diesem Zeitpunkt versuchen, das Karma "habe es dir schon seit einigen Jahren gesagt" umzukehren

@RonnyPfannschmidt Das ist so, als würde man sagen "Wir haben Ihnen 100 Mal gesagt, dass Sie das Tempolimit nicht überschreiten dürfen" und dann das Tempolimit durchsetzen, indem Sie alle Motorautos durch Flintstone-Autos ersetzen, damit die Leute das nicht überschreiten können Geschwindigkeitsbegrenzung nicht mehr.

Sie haben gerade perfekt gezeigt, dass das so schlimme Umdrehen von Wörtern - die Aussage war "Verlassen Sie sich nicht darauf, es wird kaputt gehen" - jetzt kaputt gegangen ist und plötzlich das Projekt, das Ihnen vorher gesagt hat, dass es kaputt gehen wird, schuld ist

dass man einfach die Schuld gibt, weil man nicht gerne schuld ist

@RonnyPfannschmidt

dass man einfach die Schuld gibt, weil man nicht gerne schuld ist

Sie sagen also, dass ich schuld daran bin, Pakete von Drittanbietern zu verwenden, die auf einer nicht dokumentierten Funktion von pip beruhen. Vielleicht bin ich das ... Ich hätte diese Pakete von Drittanbietern auf diese Fehler überprüfen und ein Problem oder noch besser eine PR einreichen sollen.

Aber sehen wir der Realität ins Auge: Es gibt viele Projekte da draußen, die in der Produktion verwendet werden und jetzt kaputt sind. Das ist keine Frage der Moral, keine Frage der Schuld. Es ist eine Frage von "Können Sie das bitte beheben und eine angemessene Warnung / Ablehnung angeben".

Wenn ein von Ihnen verwendetes Paket eines Drittanbieters kaputt geht, weil es sich auf undokumentierte, nicht garantierte interne APIs stützt, sollten Sie meines Erachtens einen Fehler gegen dieses Paket melden.

Es gibt eine leicht zu erkennende Grenze zwischen den Teilen von pip , die für die Verwendung durch Dritte bestimmt sind und welche nicht, und ich unterstütze nicht den Versuch, seine Entwickler zu zwingen, interne APIs zu pflegen, die es nie hätten geben sollen von Drittanbieterpaketen verbraucht. Ich unterstütze es nicht, dies als Schuld der pip -Entwickler zu betrachten und verärgerte Benutzer in ihre Richtung zu schicken. Wenn Sie auf jemanden wütend sein wollen, seien Sie wütend auf alle Pakete, die Sie verwenden und die auf internen APIs beruhen, und drängen Sie deren Betreuer, ihren eigenen Code zu reparieren.

@anx-ckreuzberger

Ich kann nicht glauben, dass dies eine Aussage des Eigentümers dieses Repositorys ist ... Sie haben buchstäblich nur "f * ck semantische Versionierung" und "wer braucht überhaupt eine Verfallsrichtlinie" gesagt.

Während ich die Frustration hier verstehe, ärgere ich mich zunehmend über die Bereitschaft der Leute, die Pip-Betreuer für Dinge zu beschuldigen, die wir nie versprochen haben.

Wenn Sie solche Vorwürfe machen wollen, untermauern Sie sie bitte mit

1. Ein Verweis auf eine Aussage von einem der Pip-Betreuer, dass wir die Verwendung der internen Pip-API im Benutzercode unterstützen.
2. Ein Zeiger auf eine Aussage von einem der Pip-Betreuer, dass Pip semantische Versionierung verwendet.

Ich glaube nicht, dass du diese Beweise finden wirst...

Sie sagen also, dass ich schuld daran bin, Pakete von Drittanbietern zu verwenden, die auf einer nicht dokumentierten Funktion von pip beruhen.

Nein, aber die Beschuldigung der Pip-Betreuer statt dieser Projekte ist nicht akzeptabel. Wir versuchen, Ihnen zu helfen, können aber nicht dafür verantwortlich gemacht werden, was diese Projekte bewirken. Äußern Sie Ihre Beschwerden mit ihnen.

Aber sehen wir der Realität ins Auge: Es gibt viele Projekte da draußen, die in der Produktion verwendet werden und jetzt kaputt sind. Das ist keine Frage der Moral, keine Frage der Schuld. Es ist eine Frage von "Können Sie das bitte beheben und eine angemessene Warnung / Ablehnung angeben".

Wir haben versucht, zu warnen. Wir haben vor Monaten Ankündigungen verschickt, wir haben Dokumente hinzugefügt, die die Situation erklären, und wir haben konsequent auf Probleme im Tracker geantwortet, die besagten, dass die Verwendung interner APIs nicht unterstützt wird. Das Hinzufügen von Verwerfungen ist bei weitem nicht so einfach, wie Sie vermuten, da Pip selbst diese Warnungen ausspucken würde (oder es eine Möglichkeit für Pip geben würde, sie auszuschalten, was andere einfach kopieren würden - wir hören bereits von Leuten, die dies planen importiere pip._internal , also wird sie selbst diese Änderung nicht aufhalten :enttäuscht:).

Was die „Behebung“ betrifft, gebe ich gerne zu, dass 9.0.2 schnell veröffentlicht wurde, um ein dringendes Problem anzugehen, und wir haben dieses Problem nicht vorhergesehen. Vielleicht ist die Veröffentlichung einer Version 9.0.3 mit einer Lebensdauer von 2-3 Wochen eine vernünftige Sache, ich glaube es selbst nicht, aber ich habe gesagt, dass wir das in Betracht ziehen werden. Ich kann dem persönlich nicht zustimmen, da ich nicht derjenige bin, der an den 9.0.x-Versionen beteiligt ist. Ich arbeite an Pip 10, wodurch diese ganze Debatte irrelevant wird, also ist dies wahrscheinlich mein letztes Wort zu diesem Thema – ich muss mich auf Dinge konzentrieren, die mit dieser Veröffentlichung zu tun haben.

Mein persönlicher Rat:

1. An 9.0.1 anheften, wenn Sie davon betroffen sind und jetzt eine Problemumgehung benötigen .
2. Seien Sie auf Pip 10 vorbereitet, wenn alle Abhängigkeiten, die Sie derzeit haben und die kaputt sind, weil sie Pip-interne APIs verwenden, wieder kaputt gehen. Drängen Sie diese Abhängigkeiten dazu, auf die Informationen zu reagieren, die wir Ihnen seit Monaten geben, und seien Sie froh, dass Sie im Voraus gewarnt wurden, dass dies passieren würde.
3. Wenn Pip 9.0.3 veröffentlicht wird, entfernen Sie den Stift.
4. Bitte testen Sie die Beta-Version von pip 10, wenn sie herauskommt, und melden Sie alle Probleme den zuständigen Parteien (Projekte von Drittanbietern, wenn sie intern bei pip anrufen, uns, wenn Sie selbst bei pip anrufen).

Ich habe das gleiche Problem mit Pip 9.0.2 und Python 2.7.14 in einem Docker-Container erlebt.
Ich kann das Problem jedoch nicht auf meinem Entwicklungscomputer außerhalb eines Docker-Containers reproduzieren.
Ich habe nach einem Pip-Import gesucht (grep'd for import.pip , from.pip , \'pip , \"pip ), konnte aber nichts finden.
Wir bei Plone verwenden einen Mechanismus, um automatisch Konfigurationen aus Paketen einzuschließen, die in einer setuptools setup.py-Datei enthalten sind, was verdächtig klingt - aber noch einmal - dieser verwendet nur __import__ und nichts von pip AFAIcansee.

Dies ist der relevante Teil des Tracebacks:

  File "/home/plone/.buildout/shared-eggs/zope.configuration-3.7.4-py2.7.egg/zope/configuration/xmlconfig.py", line 359, in endElementNS
    self.context.end()
  File "/home/plone/.buildout/shared-eggs/zope.configuration-3.7.4-py2.7.egg/zope/configuration/config.py", line 558, in end
    self.stack.pop().finish()
  File "/home/plone/.buildout/shared-eggs/zope.configuration-3.7.4-py2.7.egg/zope/configuration/config.py", line 706, in finish
    actions = self.handler(context, **args)
  File "/home/plone/.buildout/shared-eggs/z3c.autoinclude-0.3.7-py2.7.egg/z3c/autoinclude/zcml.py", line 51, in includeDependenciesDirective
    info = DependencyFinder(dist).includableInfo(['configure.zcml', 'meta.zcml'])
  File "/home/plone/.buildout/shared-eggs/z3c.autoinclude-0.3.7-py2.7.egg/z3c/autoinclude/dependency.py", line 26, in includableInfo
    module = resolve(dotted_name)
  File "/home/plone/.buildout/shared-eggs/zope.dottedname-4.2-py2.7.egg/zope/dottedname/resolve.py", line 39, in resolve
    found = __import__(used)
  File "/plone/buildout/lib/python2.7/site-packages/pip/__init__.py", line 45, in <module>
    from pip.vcs import git, mercurial, subversion, bazaar  # noqa
  File "/plone/buildout/lib/python2.7/site-packages/pip/vcs/mercurial.py", line 9, in <module>
    from pip.download import path_to_url
  File "/plone/buildout/lib/python2.7/site-packages/pip/download.py", line 40, in <module>
    from pip._vendor import requests, six
  File "/plone/buildout/lib/python2.7/site-packages/pip/_vendor/requests/__init__.py", line 98, in <module>
    from . import packages
  File "/plone/buildout/lib/python2.7/site-packages/pip/_vendor/requests/packages.py", line 12, in <module>
    sys.modules['pip._vendor.requests.packages.' + mod] = sys.modules["pip._vendor." + mod]
zope.configuration.xmlconfig.ZopeXMLConfigurationError: File "/plone/buildout/parts/instance/etc/site.zcml", line 15.2-15.55
    ZopeXMLConfigurationError: File "/plone/buildout/parts/instance/etc/package-includes/002-bda.aaf.site-configure.zcml", line 1.0-1.56
    ZopeXMLConfigurationError: File "/plone/buildout/src-aaf/bda.aaf.site/src/bda/aaf/site/configure.zcml", line 11.2-11.48
    ZopeXMLConfigurationError: File "/plone/buildout/src-aaf/bda.aaf.site/src/bda/aaf/site/configure-dependencies.zcml", line 10.2-10.39
    ZopeXMLConfigurationError: File "/plone/buildout/src-addons/plone.app.mosaic/src/plone/app/mosaic/configure.zcml", line 9.2-9.39
    ZopeXMLConfigurationError: File "/home/plone/.buildout/shared-eggs/plone.app.tiles-3.0.3-py2.7.egg/plone/app/tiles/configure.zcml", line 18.2-18.41
    ZopeXMLConfigurationError: File "/plone/buildout/src/plone.app.z3cform/plone/app/z3cform/configure.zcml", line 10.2-10.41
    ZopeXMLConfigurationError: File "/plone/buildout/src/plone.app.widgets/plone/app/widgets/configure.zcml", line 12.2-12.41
    ZopeXMLConfigurationError: File "/home/plone/.buildout/shared-eggs/Products.CMFPlone-5.1.0.1-py2.7.egg/Products/CMFPlone/configure.zcml", line 15.2-15.46
    ZopeXMLConfigurationError: File "/home/plone/.buildout/shared-eggs/plone.app.contenttypes-1.4.9-py2.7.egg/plone/app/contenttypes/configure.zcml", line 10.2-10.37
    KeyError: 'pip._vendor.urllib3.contrib'

Soweit ich weiß, bricht das Importieren von Pip - ohne es zu verwenden - bereits. Dies ist kein gutes Bürgerverhalten im Python-Land. Die Verwendung nicht zu unterstützen / keine öffentliche API bereitzustellen, ist eine Sache, nur beim Import abzubrechen, eine andere. Dies wirkt sich auf einen Großteil des automatisch inspizierenden Codes aus.

Stellen Sie sich das so vor: pip ist ein Befehlszeilendienstprogramm, keine Bibliothek. Die Tatsache, dass es in Python geschrieben ist, ist irrelevant. Das ist die Realität.

@pfmoore

Während ich die Frustration hier verstehe, ärgere ich mich zunehmend über die Bereitschaft der Leute, die Pip-Betreuer für Dinge zu beschuldigen, die wir nie versprochen haben.

Stellen Sie sich das so vor: pip ist ein Befehlszeilendienstprogramm, keine Bibliothek. Die Tatsache, dass es in Python geschrieben ist, ist irrelevant. Das ist die Realität.

Unter dem Strich ist es wirklich egal, was Sie versprochen haben. Entscheidend ist, was Sie getan haben und was die daraus resultierende Situation ist. Vielleicht haben Sie es sich als Befehlszeilenprogramm vorgestellt. Aber Sie haben es als Bibliothek veröffentlicht. Das ist die Realität:

Sie haben eine Bibliothek mit Feature X veröffentlicht. Die Leute haben angefangen, Feature X zu verwenden. Sicher, Sie sagten: „Leute, bitte verwenden Sie Feature X nicht“. Aber Sie haben es immer wieder mit Feature X veröffentlicht. Jahrelang. Und so benutzten die Leute es weiter. Zehn, vielleicht Hunderte, Tausende von Projekten, ob groß oder klein, nutzen es jetzt. Plötzlich entfernen Sie es in einem kleinen Update ohne angemessene Warnung.

Was denkst du passiert als nächstes?

Kurzfristig werden die Leute nur die alte Version pinnen und sie nicht entfernen, es sei denn, es gibt einen guten Grund.

Auf lange Sicht … hängt davon ab, wie viele Leute entscheiden, dass es kostengünstiger wäre, Sie zu ersetzen, als alles zu reparieren, was Sie kaputt gemacht haben.

@pfmoore siehst du etwas Verdächtiges in dem Traceback, auf das ich oben verwiesen habe? AFAIK verwendet keine Pip-Interna. Es ist interessant, dass die meisten Leute diese Probleme innerhalb von Docker-Containern haben.

@ all, die Betreuer wegen fehlerhaften Codes zu beschuldigen, hilft nicht bei der Lösung des Problems.

Stellen Sie sich das so vor: pip ist ein Befehlszeilendienstprogramm, keine Bibliothek. Die Tatsache, dass es in Python geschrieben ist, ist irrelevant. Das ist die Realität.

Fakt: Es kann aus irgendeinem Grund nicht importiert werden, wenn es sogar durch die automatische Überprüfung des Codes importiert wird: Alle Unterbrechungen. Ich nehme an, das passiert im Fall von @thet .
Fazit: pip muss sich vom globalen oder aktuellen virtualenv/venv-Python-Namespace isolieren, in dem es Pakete installiert. Auf diese Weise wird es nicht verschmutzt und es kommt nicht einmal zu einem versehentlichen Import.

Zunächst einmal Entschuldigung, wenn ich den Betreuern des Repos fehlerhaften Code vorgeworfen habe. Alle Anschuldigungen wurden aus Frustration erhoben und weisen, wenn überhaupt, auf die Tatsache hin, dass IMHO die Version 9.0.2 per Definition von semver eine Patch-Veröffentlichung ist (obwohl @pfmoore klargestellt hat, dass pip nicht unbedingt semver verwendet - which ist ein anderes Thema für einen anderen Tag, denke ich).

@MikeHart85

Kurzfristig werden die Leute nur die alte Version pinnen und sie nicht entfernen, es sei denn, es gibt einen guten Grund.
Auf lange Sicht … hängt davon ab, wie viele Leute entscheiden, dass es kostengünstiger wäre, Sie zu ersetzen, als alles zu reparieren, was Sie kaputt gemacht haben.

Ja schon. Ich meine, schauen Sie sich die Paketmanager von JavaScripts an: npm, bower, wool, was auch immer nächste Woche ~Jahr~ veröffentlicht wird

Nein, aber die Beschuldigung der Pip-Betreuer statt dieser Projekte ist nicht akzeptabel. Wir versuchen, Ihnen zu helfen, können aber nicht dafür verantwortlich gemacht werden, was diese Projekte bewirken. Äußern Sie Ihre Beschwerden mit ihnen.

Ich verstehe, dass meine (unsere?) Beschwerden in dieser Angelegenheit fehlgeleitet sein könnten. Obwohl Sie zugeben müssen, dass es wirklich schwierig ist, jemanden davon zu überzeugen, dass dies die Schuld von Drittanbietern ist.

Wir haben versucht, zu warnen. Wir haben vor Monaten Ankündigungen verschickt, wir haben Dokumente hinzugefügt, die die Situation erklären

War das für Pip 9.0.2 oder für Pip 10? Wenn es für pip 9.0.2 wäre, fände ich es schön, wenn es einen Hinweis im Changelog gäbe. Wie auch immer, vielen Dank, dass Sie bei der Entwicklung von pip 10 sehr proaktiv waren und Ankündigungen über die Nichtverwendung von import pip verschickten, das ist gut! Weiter so!

Das Hinzufügen von Verwerfungen ist bei weitem nicht so einfach, wie Sie vermuten, da Pip selbst diese Warnungen ausspucken würde (oder es eine Möglichkeit für Pip geben würde, sie auszuschalten, was andere einfach kopieren würden - wir hören bereits von Leuten, die dies planen import pip._internal, also wird sie selbst diese Änderung nicht davon abhalten, enttäuscht zu sein).

Ich denke nicht, dass das zu schwer wäre ... Sie haben das bereits in __init__.py :

if __name__ == '__main__':
    sys.exit(main())

Wie wäre es, wenn Sie einfach ein anderes hinzufügen?

if __name__ == '__main__':
    sys.exit(main())
else:
    logger.warning("You are importing PIP as a Python library. This behaviour is deprecated and should no longer be used. We will break the API with version 10.0!!!111eleven Please see https://pip.readthedocs.org/some_link_where_you_explain_this.html")

Bearbeiten : Sie können hier sogar eine Ausnahme auslösen, wenn Sie "streng" sein möchten, und den Untermodulen ähnliche Anweisungen hinzufügen.

Die Tatsache, dass die Leute das umgehen werden, ist eine andere Sache. Wenn Sie eine Bibliothek hacken möchten, können Sie sie jederzeit zurückentwickeln. Man findet immer einen Weg drumherum. Aber Sie sollten bei Ihren Designentscheidungen nicht alle Möglichkeiten in Betracht ziehen.

Auf lange Sicht … hängt davon ab, wie viele Leute entscheiden, dass es kostengünstiger wäre, Sie zu ersetzen, als alles zu reparieren, was Sie kaputt gemacht haben.

Ich finde diese "Bedrohung" immer amüsant. Damit einher geht ein grundlegendes Missverständnis darüber, wie viel Aufwand in so etwas wie Pip gesteckt wird und wie viel das wirklich kostet (und wie wenig die Leute bereit sind, tatsächlich dafür zu bezahlen). Wenn Sie das Gefühl haben, dass Sie es besser machen können, dann tun Sie es auf jeden Fall, ich (und ich nehme an, die anderen) begrüßen es. In den vergangenen Jahren wurde nicht unerheblich daran gearbeitet, Standards zu dokumentieren und zu entwerfen, wobei eines der ausdrücklichen Ziele darin besteht, dies zu ermöglichen.

Es ist wichtig, bei diesen Dingen den Überblick zu behalten. Es gibt ... weniger als 15? 20? Leute kommentieren, wie dies sie kaputt gemacht hat (obwohl es bei diesen Metriken immer ein „Spitze des Eisbergs“-Problem gibt), während pip 9.0.2 in der vergangenen Woche bereits das am zweithäufigsten verwendete Installationsprogramm ist (wenn man die Tage zählt, an denen es noch nicht einmal existiert hat for) und hat seit seiner Veröffentlichung 17 Millionen Dateien von PyPI heruntergeladen. Betrachtet man nur den letzten Tag, sind es 80 % des Weges, Pip 9.0.1 als das am häufigsten verwendete Installationsprogramm für PyPI zu überholen.

Obwohl ich erkenne, dass dies für einige Leute die Dinge kaputt gemacht hat, ist es eine relativ kleine Anzahl von Leuten, die entweder nicht unterstützte Dinge oder in Randsituationen tun.

Wenn ich die Zeit finde, kann ich versuchen, eine 9.0.3 zu schneiden, hauptsächlich um den Fall zu lösen, auf den @thet gestoßen ist, wo es nur ein Auto-Importer ist, der versucht, Dinge zu importieren, und sie nicht wirklich versuchen, es zu verwenden Pips interne APIs in irgendeiner Weise. Wenn dies auch dazu führt, dass das Verhalten von Personen behoben wird, die die internen APIs von Pip verwenden, werde ich mich nicht darum bemühen, sie speziell zu beschädigen, aber wenn dies nicht der Fall ist, werde ich mich auch nicht darum bemühen, das Problem zu beheben sie auch nicht ausdrücklich.

Bitte beachten Sie, dass es zu diesem Zeitpunkt viele Stunden dauert, eine 9.0.x zu veröffentlichen (die Dinge sind in master so weit auseinandergegangen, dass es einige Fummelei erfordert, um eine Veröffentlichung durchzuführen) und dass die Zeit, die zum Debuggen erforderlich ist, nicht berücksichtigt wird und das eigentliche Problem beheben. Wenn Sie die Wahrscheinlichkeit erhöhen möchten, dass dies passiert, ist das Debuggen und Beheben und Bereitstellen eines Patches (oder eines Zweigs des 9.0.2-Tags in Ihrem eigenen Fork) der beste Weg, dies zu tun.

Zunächst einmal Entschuldigung, wenn ich den Betreuern des Repos fehlerhaften Code vorgeworfen habe. Alle Anschuldigungen wurden aus Frustration gemacht

Danke schön. Der Frust ist hier groß, und das verstehe ich.

Wie wäre es, wenn Sie einfach ein anderes hinzufügen?

Gute Idee - ich wünschte, wir hätten schon vor einiger Zeit daran gedacht. Natürlich hat es jetzt keinen wirklichen Sinn, da der interne Namensraum in Pip 10 neu organisiert wird, also ist es zu spät. Diesen Trick werde ich mir sicher für die Zukunft merken.

War das für Pip 9.0.2 oder für Pip 10?

Für 10.0. Es gab keine ursprüngliche Absicht, 9.0.2 zu veröffentlichen, wir haben dies nur als Notversion getan, damit Benutzer von Mac OS nicht den gesamten Zugriff auf PyPI verlieren, wenn die TLS-Änderungen in Kraft treten.

@dstufft hat hier viel umfassender geantwortet, daher denke ich, dass dies so gelöst ist, wie es wahrscheinlich vorerst sein wird.

Ich finde diese "Bedrohung" immer amüsant.

Es ist überhaupt keine Drohung, bitte entschuldigen Sie, wenn es so rübergekommen ist.

Es ist eine Beobachtung über etwas, das allzu oft in der Softwarewelt passiert. Menschen arbeiten nicht mit Ihren Versprechungen oder Absichten. Menschen arbeiten mit dem Produkt, das Sie liefern. Wenn Ihr Produkt eine Funktion hat, auf die sich viele Menschen verlassen, können Sie es ihnen nicht mehr einfach unter den Füßen wegziehen. Wenn Sie dies tun, sehen sie Ihr Produkt als defekt an. Wenn die einzige Erklärung, die Sie geben, lautet: "Nun, wir haben das sowieso nie versprochen", dann sehen sie Ihre mangelnde Bereitschaft, ihre Bedenken anzuerkennen, als Belastung.

Je mehr dies geschieht, desto größer werden der Wunsch und die Nachfrage nach einer Alternative. Sicher, die Leute unterschätzen, wie viel Arbeit das macht. Aber das macht sie nur wahrscheinlicher , nicht weniger, an einem zu arbeiten. Sobald dieser Ball rollt, hat er ein Eigenleben.

Alternativen sind nicht immer gut. Sie neigen dazu, Dinge unordentlich zu machen. Persönlich würde ich einen einzigen Paketmanager bevorzugen. Für alles. Aber ich begnüge mich mit einem einzelnen Paketmanager für Python.

Wenn Leute berichten, dass Sie ein Feature kaputt gemacht haben, ob beabsichtigt oder nicht, sollten Sie kurz erklären, warum Sie es kaputt machen mussten oder warum es nicht praktikabel war, es zu behalten, anstatt Bedenken mit "dies wurde nicht die ganze Zeit unterstützt" abzutun.

Hey @dstufft , danke fürs Mitmachen. Dieser Thread wird ziemlich heiß!

Zunächst einmal danke ich Ihnen für Ihre Arbeit! Ich weiß, dass Wartung eine endlose, undankbare Aufgabe ist, und ich kann mir vorstellen, dass es nur noch schlimmer wird, wenn Sie ein so großes und beliebtes Projekt wie pip verwalten!

Nun zum eigentlichen Problem: Obwohl bisher zwanzig _Maintainer_ dieses Problem gemeldet haben, weiß ich, dass es bereits Tausende von _Menschen_ betrifft - einige der betroffenen Projekte sind für sich genommen massiv: Anaconda, OpenStack, SpaCy, Zappa und haben viele zehntausend Benutzer . Ich weiß, dass unser Slack-Kanal mit Diskussionen darüber überflutet ist. (Während ich dies schrieb, erschien buchstäblich eine neue Ausgabe.)

Natürlich gibt es viele wichtige Python-Projekte, die die Möglichkeit benötigen, ihre Umgebungen programmgesteuert zu inspizieren. Dies ist eine absolut vernünftige Sache, die man tun muss. Außerdem hat die Dokumentation nie davor gewarnt - und tut es immer noch nicht! (Klicken Sie auf den Docs-Link in der README-Datei dieses Repos!)

Ich denke, die Situation ist bisher:

• Angesichts des Formats der Versionszeichenfolge glaubten wir alle, dass Pip-Betreuer einer semantischen Versionierung folgen
• Die Pip-Betreuer veröffentlichten einen "Patch", der eine massiv bahnbrechende Änderung einführte
• Diese Änderung war unangekündigt und undokumentiert – und ich nehme an, unerwartet und unbeabsichtigt
• Nun, einfach import pip aufzurufen, bricht sofort ein Programm, das extrem entwicklerfeindlich ist
• Dies verursacht große Kopfschmerzen im gesamten Python-Ökosystem
• Die Dokumentation warnt nicht (und _noch_ nicht_ - klicken Sie auf den Docs-Link in der README-Datei dieses Repos) davor, pip programmgesteuert zu verwenden.
• Es gab keine Ankündigung, dass import pip diesen Schaden in einem PATCH -Update verursachen würde - diese Ankündigung kam für eine Version, die _noch nicht veröffentlicht wurde_.
• Diese Änderung wurde nicht einmal im Changelog erwähnt
• Wir wollen Pip oder die Pip-Entwickler nicht ersetzen! Wir lieben dich!
• ..aber wir wollen nicht, dass so etwas noch einmal passiert!
• ..also wollen wir, dass semver befolgt wird!
• Wir würden uns wirklich sehr über weitere PATCH freuen, die diese große Breaking Change rückgängig machen!

Die Notwendigkeit einer programmgesteuerten Möglichkeit, eine Umgebung in einer pip>=10.0.0-Welt zu inspizieren, ist ein Thema für eine andere Diskussion, aber Tatsache ist, dass uns nie gesagt wurde, dass wir pip nicht programmgesteuert im Pip verwenden sollten <=9 Welt, und es gab eine massive, unangekündigte Änderung, und wir würden es wirklich sehr gerne rückgängig machen, weil sie Tausende von Menschen negativ beeinflusst.

Danke noch einmal,
Reich

Zunächst einmal: Vielen Dank an die Pip-Betreuer für ihre Bemühungen und die Einblicke in das Projekt. Ich glaube, dass dies anderen wirklich hilft, das Problem zu verstehen (obwohl es sich lohnen könnte, einen zusammenfassenden Blog-Artikel darüber zu schreiben).

@dstufft

Es ist wichtig, bei diesen Dingen den Überblick zu behalten. Es gibt ... weniger als 15? 20? Leute kommentieren, wie dies sie kaputt gemacht hat (obwohl es bei diesen Metriken immer ein „Spitze des Eisbergs“-Problem gibt), während pip 9.0.2 in der vergangenen Woche bereits das am zweithäufigsten verwendete Installationsprogramm ist (wenn man die Tage zählt, an denen es noch nicht einmal existiert hat for) und hat seit seiner Veröffentlichung 17 Millionen Dateien von PyPI heruntergeladen. Betrachtet man nur den letzten Tag, sind es 80 % des Weges, Pip 9.0.1 als das am häufigsten verwendete Installationsprogramm für PyPI zu überholen.

Ich bin mir ziemlich sicher, dass die Metrik durch all die automatisierten pip install pip --upgrade -Befehle von Continous Integration/Delivery-Systemen stark verzerrt ist (sie sollten Caches verwenden und müssen daher nicht ständig Pakete von pypi neu installieren; aber at gleichzeitig sollte man aber auch nicht import pip machen ... so funktioniert die IT-Welt).

Die Tatsache, dass (weniger als) 15 Personen sich darüber beschwert haben, sollte zwei Dinge zeigen:

1. Ich glaube nicht, dass viele Leute 9.0.2 (in der Produktion) noch verwenden, einige versuchen möglicherweise immer noch, dieses Problem zu debuggen, und werden es "vorübergehend" beheben, indem sie stattdessen pip 9.0.1 verwenden, bis es behoben ist (oder für immer ... .) - außerdem ist einigen vielleicht noch nicht aufgefallen, dass etwas noch nicht funktioniert...
2. Es gibt Leute, die bereits innerhalb von 2 Tagen nach der Veröffentlichung darüber sprechen. Dieses Problem wird bei mehr Menschen auftreten. Warten Sie 2 Wochen und Sie könnten am Ende haben, dass sich 100 Leute darüber beschweren (z. B. wenn sie einen Sprint beenden und für QA/Staging bereitstellen). Zum jetzigen Zeitpunkt weiß man wirklich nicht, wie viele Menschen von dieser Änderung betroffen sein werden.

Wie auch immer, das Reden und Streiten über dieses Problem gibt den Leuten ein gutes Beispiel dafür, warum man sich niemals auf interne APIs verlassen sollte, und hoffentlich werden einige Paketbetreuer von Drittanbietern ihre Projekte aufgrund dessen, was hier besprochen wurde, aktualisieren.

Natürlich gibt es viele wichtige Python-Projekte, die die Möglichkeit benötigen, ihre Umgebungen programmgesteuert zu inspizieren. Dies ist eine absolut vernünftige Sache, die man tun muss. Außerdem hat die Dokumentation nie davor gewarnt - und tut es immer noch nicht! (Klicken Sie auf den Docs-Link in der README-Datei dieses Repos!)

Mir ist nicht klar, warum man davor warnen muss. Die Verwendung von pip als etwas anderes als ein Befehlszeilentool ist völlig undokumentiert . Beim Durchsuchen der Dokumentation sehe ich überhaupt keinen Hinweis auf das Importieren von Pip. Es ist, als würde man sich beschweren, weil Sie mit einigen von Chrome verwendeten .so verlinkt sind und diese die ABI-Kompatibilität gebrochen haben.

Die übliche Interpretation von SemVer ist, dass es sich auf die unterstützte öffentliche Schnittstelle (in diesem Fall die CLI) bezieht, nicht auf die undokumentierten Interna. Jeder, der die Interna verwendet, sollte sowieso seine pip -Versionen anheften, da sie willkürlichen Änderungen unterliegen.

Es gibt nichts wirklich umzukehren. Das Zurückportieren von Fixes, um zu verhindern, dass ein erheblicher Teil der Benutzer unter macOS in naher Zukunft nicht auf PyPI zugreifen kann, weist einen Fehler auf, wenn er auf die 9.0.x-Codebasis angewendet wird, die sich anscheinend nur unter nicht unterstützten Bedingungen ausdrückt. Der einzige Weg nach vorne besteht darin, zusätzliche Arbeit zu leisten, um diesen Fehler in der 9.0.x-Serie zu beheben. Wie ich schon sagte, wenn ich Zeit finde, werde ich versuchen, es zu tun, wenn Sie die Wahrscheinlichkeit erhöhen wollen, dass es passiert, dann stellen Sie einen Patch bereit.

Die Dokumentation warnt nicht davor, weil es nicht möglich ist, eine erschöpfende Liste von Dingen bereitzustellen, die Sie möglicherweise mit pip machen könnten, die aber nicht unterstützt werden. Stattdessen verlassen wir uns auf den ziemlich verbreiteten Ansatz, zu dokumentieren, was unterstützt wird, und alles, was nicht dokumentiert ist, sollte als nicht unterstützt angesehen werden (und wenn Sie sich auf etwas verlassen wollen, das nicht dokumentiert ist, öffnen Sie ein Problem, indem Sie darum bitten, dass es dokumentiert und somit unterstützt wird ).

Längerfristig werden wir wahrscheinlich zu einem datumsbasierten Veröffentlichungsschema übergehen, um (hoffentlich) jegliche Verwirrung darüber zu beseitigen, ob wir Semver sind oder nicht.

von meinem Iphone gesendet

Am 20. März 2018 um 11:02 Uhr schrieb Rich Jones [email protected] :

Hey @dstufft , danke fürs Mitmachen. Dieser Thread wird ziemlich heiß!

Zunächst einmal danke ich Ihnen für Ihre Arbeit! Ich weiß, dass Wartung eine endlose, undankbare Aufgabe ist, und ich stelle mir vor, dass es nur noch schlimmer wird, wenn Sie ein so großes und beliebtes Projekt wie Pip verwalten!

Nun zum eigentlichen Problem: Obwohl bisher zwanzig Betreuer dieses Problem gemeldet haben, weiß ich, dass es bereits Tausende von Menschen betrifft – einige der betroffenen Projekte sind für sich genommen massiv: Anaconda, OpenStack, SpaCy, Zappa und haben viele zehntausend Benutzer . Ich weiß, dass unser Slack-Kanal mit Diskussionen darüber überflutet ist. (Während ich dies schrieb, erschien buchstäblich eine neue Ausgabe.)

Natürlich gibt es viele wichtige Python-Projekte, die die Möglichkeit benötigen, ihre Umgebungen programmgesteuert zu inspizieren. Dies ist eine absolut vernünftige Sache, die man tun muss. Außerdem hat die Dokumentation nie davor gewarnt - und tut es immer noch nicht!

Ich denke, die Situation ist bisher:

Angesichts des Formats der Versionszeichenfolge glaubten wir alle, dass Pip-Betreuer einer semantischen Versionierung folgen
Die Pip-Betreuer veröffentlichten einen "Patch", der eine massiv bahnbrechende Änderung einführte
Diese Änderung war unangekündigt und undokumentiert – und ich nehme an, unerwartet und unbeabsichtigt
Nun, nur der Aufruf von import pip bricht sofort ein Programm, das extrem entwicklerfeindlich ist
Dies verursacht große Kopfschmerzen im gesamten Python-Ökosystem
Die Dokumentation warnt nicht (und tut es immer noch nicht – klicken Sie auf den Docs-Link in der README-Datei dieses Repos) vor der programmgesteuerten Verwendung von pip.
Es gab keine Ankündigung, dass Import Pip diesen Schaden in einem PATCH-Update verursachen würde - diese Ankündigung kam für eine Version, die noch nicht veröffentlicht wurde.
Diese Änderung wurde nicht einmal im Changelog erwähnt
Wir wollen Pip oder die Pip-Entwickler nicht ersetzen! Wir lieben dich!
..aber wir wollen nicht, dass so etwas noch einmal passiert!
..also wollen wir, dass semver befolgt wird!
Wir würden uns wirklich sehr über einen weiteren PATCH freuen, der diese große Breaking Change rückgängig macht!
Die Notwendigkeit einer programmgesteuerten Möglichkeit, eine Umgebung in einer pip>=10.0.0-Welt zu inspizieren, ist ein Thema für eine andere Diskussion, aber Tatsache ist, dass uns nie gesagt wurde, dass wir pip nicht programmgesteuert im Pip verwenden sollten <=9 Welt, und es gab eine massive, unangekündigte Änderung, und wir würden es wirklich sehr gerne rückgängig machen, weil sie Tausende von Menschen negativ beeinflusst.

Danke noch einmal,
Reich

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder schalten Sie den Thread stumm.

@Miserlou

Angesichts des Formats der Versionszeichenfolge glaubten wir alle, dass Pip-Betreuer einer semantischen Versionierung folgen

Können Sie mir als jemand, der Semver entschieden ablehnt, mitteilen, welches Format meine Versionszeichenfolgen haben sollten, um diese Verwirrung zu beseitigen? "Drei gepunktete Zahlen" bedeutet für mich nicht "semver folgt strikt", daher kommt diese Annahme überraschend.

Als Antwort auf diesen Kommentar : Unabhängig davon, ob pip sich an semver hält oder verspricht, sich daran zu halten, die Verwendung eines major.minor.micro -Versionierungsschemas beinhaltet immer noch das implizite Versprechen einer Art von Zurückhaltung in Bezug auf Micro-Releases. Wenn ein kompatibler Release -Pin wie ~= 9.0.1 nicht ausreicht, um Benutzer vor unerwarteten Unterbrechungen der Abwärtskompatibilität zu schützen, bleibt als einzige sichere Alternative der einfache Versionsabgleich . Wenn nicht beabsichtigt ist, mehr als Versionsabgleich zu unterstützen, könnte pip genauso gut zu einem Versionsschema im Chrome-Stil wechseln, das nur eine monoton ansteigende Komponente hat.

Bearbeiten: Ich sehe, dass @dstufft bereits vorgeschlagen hat, sich in diese Richtung zu bewegen, indem datumsbasierte Versionen übernommen werden. Ich denke, das wäre ein unglücklicher Kollateralschaden, der aus diesem Vorfall resultieren würde.

Also ja, als Benutzer eines von Freiwilligen betriebenen Softwareprojekts müssen wir unsere Erwartungen mit einer Wertschätzung für die Art der Beziehung zwischen Benutzer und Betreuer in Einklang bringen. Es ist auch klar, dass diese Veröffentlichung nicht dazu gedacht war, import pip plötzlich zum Scheitern zu bringen. Auf der anderen Seite denke ich jedoch, dass es vernünftig ist, dass die Leute frustriert sind, dass diese Art von Regression in einer Mikroversion auftritt, und die Veröffentlichung einer 9.0.3-Version, die das Problem behebt, scheint eine vernünftige Abhilfe zu sein.

Nebenbei kann ich dies in einer virtuellen Umgebung (2 oder 3, es spielt keine Rolle) mit den folgenden Schritten reproduzieren:

virtualenv -p python3 /tmp/pip
/tmp/pip/bin/pip install -e path/to/clone/of/pip/9.0.2
/tmp/pip/bin/pip install requests
/tmp/pip/bin/python

Dann in der Python-Shell:

>>> import requests
>>> import pip

Wenn Anfragen noch nicht importiert wurden, ist import pip erfolgreich.

unerwartete Brüche in der Abwärtskompatibilität

Bitte geben Sie mir an, wo import pip als stabile API dokumentiert wurde, die unter die Abwärtskompatibilitätsversprechen fällt, die wir machen? Ich möchte sicherstellen, dass ich diese Dokumentation entferne, da wir diese Verwendung ausdrücklich nicht unterstützen.

Es sei denn, Sie sind der Meinung, dass absolut nichts kaputt gehen kann, auch nicht unterstützte, ungetestete Anwendungen. In diesem Fall möchten Sie wahrscheinlich == anheften, weil es völlig unbekannt ist, was Sie zu diesem Zeitpunkt alles verwenden, und jede Änderung möglicherweise zu einer bahnbrechenden Änderung für jemanden wird (obligatorisches xkcd ).

pip ist der Paketmanager von Python. Python ist eine Programmiersprache. Menschen müssen ihre Umgebung programmatisch inspizieren. 1+1=2.

Es war völlig vernünftig, dass die Leute annahmen, dass dies der richtige Weg war, dies zu tun. Es gab nichts - und es gibt immer noch _ - nichts in der Dokumentation, das besagte, dass man dies _nicht_ tun sollte. Zur Erinnerung: Es gibt über 700.000 Bewerbungen, die zu demselben Ergebnis gekommen sind! Außerdem - es geht nicht anders!

Nur weil etwas in ReadTheDocs nicht dokumentiert ist, bedeutet das nicht, dass es verboten ist – wir alle begegnen und verwenden jeden Tag Projekte, die einfach Code auf diese Weise bereitstellen.

Wenn überhaupt, scheint die Tatsache, dass pip überhaupt eine Befehlszeilenschnittstelle _hat_, ein guter Hinweis darauf zu sein, dass es als Bibliothek verwendet werden kann, da es bereits einen Python-Client hat!

Darüber hinaus sprechen wir nicht über private APIs mit einem _ Namensraum, wie es die Konvention ist, oder sogar über eine bestimmte öffentliche Methode, wir sprechen nur über das _einfache Aufrufen von import_, was diesen katastrophalen Fehler verursacht.

Es gab - und gibt es immer noch - nichts in der Dokumentation, das besagt, dies nicht zu tun.

https://pip.pypa.io/en/latest/user_guide/#using -pip-from-your-program

Wenn Sie auf den "Docs"-Link von _diesem Repo_ klicken, gelangen Sie nicht zu dieser Seite. Niemand verweist zuletzt. Ihre eigenen Links zur Dokumentation verlinken nicht auf die neueste. Es gibt keine Möglichkeit, auf diese Seite zu gelangen. Alles geht nach Stable, was diesen Abschnitt nicht enthält.

@Miserlou Ich denke, dieser Hinweis ist eine Freundlichkeit für Leute, die irgendwie denken, dass sie die Interna eines Befehlszeilentools importieren sollten, nur weil es zufällig in Python implementiert ist und diese Interna importierbar sind.

Ich verstehe, dass Sie die öffentliche Schnittstelle von pip anders interpretieren als ich, die Entwickler und die meisten Leute, die pip als CLI-Programm betrachten, aber was ist der eigentliche Schaden davon? Einfach pip != 9.0.2 und fertig.

Es ist offensichtlich, dass wir uns zu diesem Zeitpunkt alle auf derselben Seite darüber befinden, was Teil der unterstützten öffentlichen API ist und was nicht, und es gibt nichts, was jetzt getan werden kann, um alle irgendwie rückwirkend darauf aufmerksam zu machen.

Um ehrlich zu sein, haben die Betreuer von pip bereits erklärt, dass sie versuchen werden, dieses Problem zu beheben, wenn es die Zeit erlaubt, obwohl jeder ermutigt wird, eine Pull-Anfrage einzureichen, um die Dinge zu beschleunigen.

Ich denke, im Moment können wir nur Bibliotheken von Drittanbietern auf dieses Problem aufmerksam machen und sie auf dieses Problem hinweisen. Langfristige Bibliotheken von Drittanbietern müssen dieses Problem sowieso beheben, und hoffentlich auf eine Weise, bei der sie nicht import pip , sondern pip über die Befehlszeile aufrufen (mit Unterprozessen oder ähnlichen Python-Befehlen).

Ich glaube, dass diese Diskussion wahrscheinlich nicht produktiv ist und dass es wirklich nichts weiter zu sagen gibt. Es gibt:

• Eine angemessene Beschreibung des Problems.
• Mögliche Problemumgehungen, die jemand anwenden könnte, wenn er darauf stößt.
• Begründung, warum wir dies gemäß unseren Richtlinien zur Abwärtskompatibilität nicht als Breaking Change betrachten.
• Eine Erklärung, dass ich versuchen werde, Zeit zu finden, um das Problem zu beheben (obwohl keine Versprechungen dazu gemacht werden).
• Ein Call-to-Action, den man machen kann, wenn jemand, der davon betroffen ist, es wahrscheinlicher machen möchte, dass ein 9.0.3 mit dem Fix existiert.

An diesem Punkt dient die Diskussion keinem wirklichen Zweck, außer alle Beteiligten weiter zu frustrieren, daher verabschiede ich mich vorerst von diesem Thema. Dieses Problem wird entweder mit der Veröffentlichung von 10.0 oder 9.0.3 geschlossen. Wenn sich jemand um den Call To Action bemüht, kann er entweder eine Pull-Anfrage öffnen oder einen Diff zu diesem Thema einreichen.

Um dieses Do-not-import-pip-Mantra sichtbarer zu machen, wie wäre es, den Namensraum in "_pip" umzubenennen? Dies weist darauf hin, dass das Ganze auf Namensebene nicht zur öffentlichen Verwendung bestimmt ist.
Außerdem wäre es einfacher, dem Auto-Inspecting-Code mitzuteilen, dass er nicht auf Dinge achten soll, die mit einem Unterstrich beginnen. Nun, letzteres würde auch Änderungen im Beteiligungsinspektionscode erfordern. Aber zumindest gibt es eine Chance, damit (konventionell) zu automatisieren, ohne schwarze Listen zu verwalten.

Ok, das Letzte, was ich schwöre - Pip 10 hat bereits den gesamten relevanten Code nach pip._internal verschoben (wir haben _pip nicht verwendet, weil das python -m pip , das unterstützt wird, kaputt machen würde).

Kann jemand überprüfen, ob https://github.com/pypa/pip/pull/5100 dies für sie löst?

Streichen Sie das, ich denke, #5100 ist falsch, könnten Sie stattdessen bitte https://github.com/pypa/pip/pull/5101 überprüfen.

@dstufft Ich kann bestätigen, der Fix in #5101 löst das Problem für mich.

Danke @dstufft für deine Zeit, dies anzusprechen. Ich werde mit den Anaconda-Teams zusammenarbeiten, um dieses Problem zu kommunizieren und ihnen dabei zu helfen, vom Importieren von Pip wegzukommen.

Für die Aufzeichnung in diesem Thread hat # 5101 auch mein Problem gelöst.

Dito, #5101 ermöglicht den Import innerhalb unseres Tools. Vorsichtsmaßnahme: Ich habe weder das gepatchte Pip noch unser Tool ausgiebig getestet.

Dies sollte in 9.0.3 behoben sein.

Vielen Dank für die schnelle Lösung von jemandem, der nie in seinem Leben import pip geschrieben hat, aber ein Verbraucher eines Pakets war, das dies getan hat. Nach dem Lesen dieses Threads klingt es so, als hätten viele Apps Pip importiert, unwissentlich gegen Best Practices, und viele Entwickler und Benutzer sind möglicherweise von v9.0.2 und v10 betroffen.

Als Zweites/Drittes/Ntes wurde eine richtige Abwertungswarnung hinzugefügt, um die Dinge reibungsloser zu gestalten. vielleicht sogar ein Beitrag auf pypi.python.org?

Hurra! Danke dafür!

Ich würde mich auch sehr über eine Verfallswarnung und, was noch wichtiger ist, über eine ordnungsgemäße Anleitung zur programmgesteuerten Inspektion von Python-Umgebungen in einer pip10-Welt freuen! Angesichts der Tatsache, dass über 700.000 Anwendungen von diesem Fehler betroffen waren, besteht eindeutig ein Bedarf dafür.

pip list --format=json ?

Zunächst danke ich Ihnen allen, die zu Pip People beitragen, denn es deckt alle meine Anwendungsfälle mit ein paar benutzerfreundlichen Optionen und Argumenten ab.

Müssen wir aufgrund dieses „überraschend weit verbreiteten und nützlichen undefinierten Verhaltens“ eine Piplib als libgit2 für Git erstellen? Bitte beachten Sie, dass libgit2 keinen Code mit Git teilt und von einer anderen Gruppe von Git gepflegt wird. Und es ist gut für das Git-Ökosystem. Vielleicht deckt Piplib einige interessante Anwendungsfälle ab, die wir nicht erwartet haben.

Hier ist eine ähnliche Geschichte: https://public-inbox.org/git/1267957655.3759.29.camel@mattotaupa/T/

@drunkwcodes Ich vermute, dass das, was Sie vorschlagen, bereits in den vorhandenen Paketen implementiert ist, die in der Pip-Dokumentation erwähnt werden, packaging , setuptools und distlib . Soweit ich diesem Thread entnehmen kann, gibt es kein Problem mit einer Funktionslücke, aber einige Leute haben Probleme mit Tools, die versuchen, jedes Modul zu importieren und zu überprüfen, und Importfehler als schwerwiegende Fehler behandeln.

Es scheint mir, dass solche Tools dieses Problem umgehen könnten, indem sie Importanweisungen in einen Try/Except-Block einschließen, aber das scheint auch ein fragwürdiger Präzedenzfall zu sein. Angesichts der Veröffentlichung von Pip 9.0.3 denke ich jedoch, dass es sich wahrscheinlich nicht lohnt, das Importproblem zu diskutieren, es sei denn, das Problem tritt in Pip 10 erneut auf. Wie auch immer, solange die Betreuer sich nicht die Mühe machen, dies zu tun import pip scheitern oder Patches, die solche Fehler beheben, kurzerhand ablehnen, gäbe es Gemeinsamkeiten, auf denen man stehen kann.

@sruggier Die erwähnten Pakete sind alle gut, und WheelFile.install() braucht auch mehr Werbung. Aber der One-Stop-Service pip.main() ist mit all dem oben Genannten unersetzlich. Es ist immer noch einen Versuch wert.

Das Wichtigste ist, dass ich hoffe, dass diese Anforderungen von einem anderen Projekt erfüllt werden und pip10 ohne zusätzliche Garantien reibungslos ankommt. Die Abwertung und Minimierung der Codebasis sind die wichtigsten Punkte für eine Hauptversion.

Konkrete Umsetzungsdetails für eine permanente Infrastruktur-„Software“ sind lächerlich. Sie können Betreuer nicht nach dem dokumentierten Missbrauchsfall beurteilen und das Pip-Rad zurückhalten.

Wenn Sie darauf bestehen, pip als Bibliothek zu verwenden, müssen viele Annahmen überdacht werden.

@drunkwcodes Nur um es klarzustellen, pip.main() ist die am einfachsten zu ersetzende Verwendung - Sie müssen einfach subprocess.run([sys.executable, '-m', 'pip', <rest of args>]) verwenden.

Der Grund, warum WheelFile.install() nicht beworben wird, ist auch, dass das Wheel-Projekt auch angegeben hat, dass es keine für den Benutzer sichtbare API bereitstellt - wir haben Wheel ursprünglich in den Pip-Dokumenten erwähnt, es aber auf ihre Anfrage entfernt. Der Rad-PEP ist jedoch ziemlich klar darüber, wie Sie ein Rad installieren - es ist nicht schwer, es in einem Modul eines Drittanbieters zu implementieren.

Ich schätze die Arbeit, die Sie alle an Pip leisten, und weiß, dass es nicht einfach ist. Aber fürs Protokoll:

Ich bin ein wenig enttäuscht, dass die Leute sich nicht bereits von Import Pip entfernt haben. Die von diesem Problem betroffenen Personen müssen sich noch auf Pip 10 vorbereiten

spaCy hat sich von import pip entfernt. Aber einige Leute verwenden immer noch spaCy 1, das pip importiert hat --- und aus offensichtlichen Gründen pip nicht an eine Patch-Veröffentlichung gebunden hat. Wenn die Änderung bei v10 eingetreten wäre, wären unsere alten Versionen nicht betroffen gewesen. Wir haben gerade einen Hotfix herausgegeben, um dies zu beheben.

richtige Anleitung zur programmgesteuerten Inspektion von Python-Umgebungen in einer pip10-Welt

Wie ist die Position von PyPA zu distlib? Pip verwendet es offensichtlich in gewisser Weise, aber es verwendet auch Verpackungen, die distlib angeblich missbilligt.

Wenn es keine offizielle Position gibt, dann würden zumindest aktuelle Gedanken und Meinungen von pip's Hauptbetreuern sehr geschätzt. Wenn es an anderer Stelle relevante Diskussionen zu diesem Thema gibt, reicht mir ein einfacher Hinweis auf andere Diskussionen.

Mir ist nicht bekannt, dass distlib die Paketierung ablehnt. Es erwähnt "distutils2/packaging", aber distutils2 war etwas anderes.

Meine persönliche Ansicht ist, dass sowohl distlib als auch das Paketieren vollkommen vernünftige Dinge sind. Sie sollten sie selbst bewerten, um zu bestätigen, dass sie Ihren Anforderungen entsprechen, natürlich genau wie jede andere Abhängigkeit, auf die Sie sich verlassen.

Vielleicht ist Ablehnen dann zu stark formuliert. Die Quelle meines derzeitigen Verständnisses:

https://distlib.readthedocs.io/en/latest/overview.html#distlib -evolved-out-of-packaging

Ah, das ist eine andere "Verpackung" - es war das vorgeschlagene stdlib-Modul, das distutils ersetzen sollte. Es ist völlig anders als das PyPI-Projekt packaging . Es könnte sich lohnen, das distlib-Projekt zu fragen, um diese Unterscheidung etwas besser zu verdeutlichen.

Es könnte sich lohnen, das distlib-Projekt zu fragen, um diese Unterscheidung etwas besser zu verdeutlichen.

Schon erledigt :) Siehe: https://bitbucket.org/pypa/distlib/issues/100/clarify-project-positioning-and-status

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.