<p>pip install --editable und pip install kollidieren für Namespace-Pakete</p>

Gleiches Problem hier :(

Ich habe einen Code zum Testen dieses Fehlers veröffentlicht: http://public.hg.stephane-klein.info/hgwebdir.cgi/test_pip_namespace_bug_3/

Die Wurzel des Problems liegt darin, dass setuptools zwei Methoden enthält, mit denen Namespace-Pakete funktionieren: die Methode __init__.py (die dokumentiert ist und von Menschen verwendet werden kann) und die Dateimethode ...-nspkg.pth Wird nur mit --single-version-externally-managed (was pip verwendet). Die beiden Methoden sind nicht miteinander kompatibel.

Nach einigen Diskussionen mit mitsuhiko und anderen im IRC scheint es die beste (teilweise) Lösung für pip zu sein, "pip install -e" eine modifizierte Version der Standarddatei setuptools ... nspkg.pth für jedes von der Entwicklung installierte Paket hinzufügen zu lassen . (Die erforderlichen Änderungen bestehen darin, anstelle von sitedir den Pfad "Egg-Link entwickeln" zu verwenden und die Prüfung auf " init .py" vollständig zu überspringen, da ein von der Entwicklung installiertes Namespace-Paket eine " init .py" enthält.) Dies bedeutet, dass pip zumindest mit sich selbst kompatibel ist (pip-installierte und pip-editierbar installierte Namespace-Pakete arbeiten zusammen). Pip-installierte und Setuptools / Distribute-installierte Namespace-Pakete sind nicht kompatibel.

Ich wurde kürzlich auch davon gebissen. Ein weiteres Problem, das dadurch verursacht wird, ist, dass für das Namespace-Paket kein __init__.py installiert ist (vorausgesetzt, Sie haben nur ein Paket in diesem Namespace installiert und es wurde installiert - einzelne Version extern verwaltet) bricht die Modulsuche der Nase ab. Vielleicht ist das die Schuld der Nase, aber ich denke immer noch, dass es kein Python-Paket ist, wenn ein Verzeichnis kein __init__.py .

Ich denke, Pip sollte irgendwie einfach das nspkg.pth-Ding komplett töten und das __init__.py installieren. Solange das Paket selbst korrekt entworfen wurde (dh das __init__.py ist leer, mit Ausnahme von extens_path / declare_namespace), sollte es kein Problem sein. --single-version-extern-verwaltet wurde für Systempackager entwickelt, aber sie werden pip überhaupt nicht verwenden. Ich frage mich also, ob es eine Möglichkeit gibt, dieses Verhalten vollständig zu deaktivieren, ohne zu aufdringlich zu sein.

+1 für den Wechsel von '--single-version-extern-verwaltet': Diese Option ist überhaupt nicht für die Anwendungsfälle von pip vorgesehen. Wenn pip nicht mindestens so gute Arbeit bei der Installation von Sachen leisten kann wie easy_install, wozu dient es dann?

Ein vollständiger Wechsel von --single-version-externally-managed wird nicht passieren. Flachinstallationen sind eine Funktion. Ein Wechsel davon nur bei Namespace-Paketen ist eine Möglichkeit, die ich in Betracht ziehen würde, um diese Probleme zu vermeiden. Ich mag es nicht, aber es scheint keine großartige Option zu geben, da die beiden in setuptools / Distribute integrierten Arten der Unterstützung von Namespace-Paketen inhärent inkompatibel sind.

Zu sagen, dass --single-version-externally-managed "nicht für Pips Anwendungsfälle gedacht ist", liegt irgendwo zwischen falsch und einem roten Hering. Das Flag soll flache Einzelversionen ermöglichen, die von einem anderen Tool als easy_install verwaltet werden. Genau dafür verwendet Pip es. Die Tatsache, dass der Autor von setuptools ursprünglich (und fälschlicherweise) dachte, dass nur Systempackager an einer solchen Funktion interessiert wären, ist irrelevant.

Der Bruch hier ist ein inhärenter Fehler in der Technik, die setuptools für Namespace-Pakete mit diesem Flag verwendet, und der Fehler ist genauso vorhanden, wenn das Flag von seiner ursprünglich beabsichtigten Zielgruppe, den Systempackagern, verwendet wird (ich habe den Fehler zum ersten Mal in der Interaktion zwischen einem " setup.py "installiertes Paket und ein vom Systempaket installiertes Namespace-Paket entwickeln".

Ich habe auch diesen Fehler. Ich denke, dies ist einer dieser unlösbaren Fehler, die hier bleiben werden. Naja.

Ich würde einen Patch akzeptieren, um --single-version-externally-managed zu vermeiden, wenn ein Namespace-Paket beteiligt ist, was meines Erachtens dieses Problem lösen würde. Ich habe derzeit keine Pläne, diesen Patch zu schreiben.

Warum nicht eine Option , die wir weitergeben pip install nicht verwenden --single-version-externally-managed ? Ich teste, indem ich auskommentiere, dass in ./pip/req.py:568 und allen Paketen, die jetzt im Eierverzeichnis installiert sind, genau wie bei easy_install. Manchmal möchte ich dies tun, wenn ich sowohl pip als auch easy_install verwendet habe, damit sich mein site-packages nicht mit einigen flach installierten Paketen mischt und andere nicht.

Ich sehe kein Problem mit der Option --egg , --single-version-externally-managed zu deaktivieren.

https://github.com/k4ml/pip/commit/93cd6b16207d2eba201a7fc3126624b616f5e6f9

Kann jemand einen Kommentar abgeben, wenn ich mich in die richtige Richtung bewege? Dies ist mein erstes Mal, dass ich Pip-Code hacke. Dies basiert auf meinem kurzen Einblick in einen Teil davon, nur um pip install --egg somepackages alles in ein einzelnes Ei-Verzeichnis zu installieren.

Kann jemand einen Kommentar abgeben, wenn ich mich in die richtige Richtung bewege?

Sieht gut aus für mich, braucht nur einen Test. Tests sind meistens auf hohem Niveau
Integrationstests mit ScriptTest sollten einfach zu schreiben sein
vorhandene Beispiele. In diesem Fall möchten Sie nur die Installation testen
Ein Beispielpaket führt zu einer .egg-Datei, nicht zu einer flachen Installation
Site-Pakete. Sie sollten ein Paket aus dem lokalen Dateisystem installieren.
nicht das Netzwerk: tests/packages/FSPkg wird wahrscheinlich gut funktionieren. Hinzufügen
Der Test auf tests/test_basic.py ist in Ordnung.

Vielen Dank!

Pull-Anfragen - https://github.com/pypa/pip/pull/541

Ich denke auch darüber nach, es möglich zu machen, dieses Flag in pip.conf zu setzen. Was denkst Du darüber ?

Ich denke auch darüber nach, es möglich zu machen, dieses Flag in pip.conf zu setzen. Was denkst Du darüber ?

Lassen Sie uns über die Pull-Anfrage diskutieren.

Zusammengeführte Pull-Anforderung Nr. 541, die eine Problemumgehung bietet. Danke @ k4ml!

Hinweis: Die Option --egg , die zur Behebung dieses Problems hinzugefügt wurde, wird möglicherweise entfernt, ohne dass eine alternative Problemumgehung angeboten wird. Siehe Diskussion in # 1749

Hier ist ein Skript, um dieses Problem tatsächlich zu reproduzieren

https://gist.github.com/Ivoz/d9bff05069e0ec53e6ea

Ich bin kein großer Fan der --egg-Lösung, aber dafür muss es eine weniger umständliche Problemumgehung geben.

Ohne Problemumgehung kann ich während der Entwicklung --editable nicht einmal verwenden und dann einfach bearbeiten und testen. Jedes Mal, wenn ich meinen Code speichere, muss ich pip install -I --no-deps . ausführen, was sehr alt und zerbrechlich wird (lesen Sie: manchmal vergesse ich es).

Ein Teil des Problems bei der Art und Weise, wie sich dieses gesamte Problem manifestiert, besteht darin, dass es still ist. Sie können ein Modul einfach nicht importieren, obwohl es installiert ist und pip Ihnen mitteilt, dass es vorhanden ist.

Es wäre ein positiver Schritt, Pip dazu zu bringen, sich zu beschweren, wenn versucht wird, bearbeitbare Pakete als Teil eines Namespace zu installieren, in dem bereits ein nicht bearbeitbares Paket in diesem Namespace installiert ist. oder alternativ, um sich zu beschweren, wenn versucht wird, ein nicht bearbeitbares Paket zu installieren, das Teil eines Namespace ist, in dem bereits ein bearbeitbares Paket in diesem Namespace installiert ist.

Eine andere Option, wenn wir tatsächlich möchten, dass Namespace-Pakete und bearbeitbare Installationen immer funktionieren, könnte sein, dass pip, wenn ein Namespace-Paket als bearbeitbar installiert wird, alle anderen Pakete in diesem Namespace neben dem gewünschten Paket als bearbeitbar neu organisieren kann.

Ich habe 2 Vorschläge zur Behebung dieses Problems in setuptools https://bitbucket.org/pypa/setuptools/issue/250/develop-and-install-single-version eingereicht

Putten

importiere pkg_resources; pkg_resources.fixup_namespace_packages ('')

in einer .pth-Datei in Site-Paketen scheint ausreichend zu sein, damit pip install -e installierte Dinge korrekt funktionieren.

Dies betrifft auch zwei Pakete mit demselben Top-Namespace, wobei beide als bearbeitbar installiert sind. Die zweite Paketinstallation ist fehlerhaft.

Wir verwenden einen globalen Namespace für alle unsere Anwendungen und daher ist dieses Problem etwas schwierig (+ das Problem, dass setuptools keine Räder unterstützt, was aufgrund des Fehlens eines Compilers auf unseren Windows-Bereitstellungsplattformen erforderlich ist). Außerdem scheinen alle empfohlenen Lösungen in unserem Setup mit Python 3.4 fehlzuschlagen.

Nachdem mir klar wurde, dass pip install -e setup.py develop für das Projekt ausführt, das bearbeitet werden kann, habe ich mich in die setuptools-Prozedur eingebunden und eine * .pth-Datei geschrieben, die die Namespace-Pakete beim Python-Prozess "einführt" beginnt. Dies behebt das Problem für uns bei Verwendung von setuptools 18 und pip 7.1.0.

Eine Beispieldatei setup.py, die zeigt, wie dies erreicht werden kann, finden Sie hier:
https://gist.github.com/cbrand/a1624ac3e9c81ce45fcb

Ich hoffe, dass dies auch für andere Menschen hilfreich ist.

Ich bin heute auch auf dieses gestoßen und es hindert mich daran, von Buildout zu Virtualenv + Pip zu wechseln.

Ich habe eine kleine Demo erstellt, um das Problem zu demonstrieren. Um es zu testen, entpacken Sie die Datei .tar.gz und führen Sie das Skript {{run-me}} aus. Kann beim Testen eines Fixes hilfreich sein.

Ich treffe auch dieses Problem.

Beim Versuch zu verstehen, stieß ich auf die von @carljm unter https://github.com/pypa/pip/issues/3#issuecomment -1659959 vorgeschlagene Lösung, dh _have "pip install -e" fügte eine modifizierte Version des Standards hinzu setuptools ... nspkg.pth Datei für jedes von der Entwicklung installierte package_.

Ich habe manuell mit diesem Ansatz experimentiert und es scheint gut zu funktionieren. Es sieht so aus, als würde es gleichzeitig die Frage nach flachen Quellbäumen mit fehlenden Namespace-Paketen lösen, wie in # 3160 beschrieben.

Ich frage mich also, ob dieser Ansatz noch als gültig angesehen wird, ob es einen Versuch gab, ihn zu implementieren, und ob ein Patch dafür in Betracht gezogen würde.

Also ... keine Hoffnung, dass dies in naher Zukunft behoben wird?

Ein Nebeneffekt von pkg_resources.get_distribution() bewirkt, dass der Import funktioniert. Wir haben dies festgestellt, als Code, der Einstiegspunkte geladen hat, ordnungsgemäß funktioniert hat, während die Python-Shell fehlgeschlagen ist.

Dies kann auch erklären, warum eine Ipython-Shell keine Probleme beim Importieren der Pakete hat.

Ich bin erstaunt, dass dieser Fehler nach 5 Jahren immer noch offen ist und keine klare Lösung gefunden wurde.

Wenn es Ihre Aufgabe ist, Frameworks zu einem einheitlichen Framework zusammenzufügen, bringt pip Ihren Job zum Kotzen. Ich habe ehrlich gesagt keine Ahnung, wie ich aufgrund dieses Fehlers mit meiner Arbeit fortfahren soll.

Dies ist ein schwer zu behebendes Problem in hauptsächlich von Freiwilligen durchgeführten Projekten.
Fühlen Sie sich frei, die notwendige Unterstützung in Setuptools hinzuzufügen, damit Pip dies richtig machen kann

Brandon Github [email protected] schreibt:

Ich bin erstaunt, dass dieser Fehler nach 5 Jahren immer noch offen ist und keine klare Lösung gefunden wurde.

Ja, schade.

Wenn es Ihre Aufgabe ist, Frameworks zu einem einheitlichen Framework zusammenzufügen,
pip bringt deinen Job zum Kotzen. Ich habe ehrlich gesagt keine Ahnung, wie ich vorgehen soll
meine Arbeit aufgrund dieses Fehlers.

Ich habe kürzlich den oben erwähnten Hack fixup_namespace_packages ('') angewendet und
es scheint zu funktionieren: Ich habe ein z.pth in den Site-Paketen des venv erstellt
enthält nur import pkg_resources; pkg_resources.fixup_namespace_packages('')

Einen Versuch wert, IMHO.

Nur noch eine Beule hier!

Ich möchte nur erwähnen, dass jedes einzelne Mark- Paket Namespaces verwendet (einige Pakete mit bis zu vier oder fünf) und dass dieses spezielle Problem ein Fluch meiner Existenz war, wenn es darum geht, neuen Benutzern bei der Einrichtung von Entwicklungstools zu helfen . Ich habe nur knapp 60 Pakete damit. Interessant ist auch die Note entry_points , da praktisch jedes Paket, das zu einem Namespace beiträgt, auch entry_points beiträgt.

Der pip -Ansatz funktioniert meiner Erfahrung nach nur, wenn _jedes_ Paket von der Festplatte installiert und bearbeitet werden kann, die im Namespace zusammenarbeitet. Wenn ein Paket installiert wird, das nicht über Pip bearbeitet werden kann, beginnt sich der gesamte Wollknäuel mit einigen sehr, sehr stumpfen Symptomen für neue Benutzer zu entwirren. (Zum Beispiel zeitweise importierbare Module; eine allgemeine Überprüfung des Imports des übergeordneten Namespace und der Überprüfung von namespace.__path___ hat das fehlerhafte Paket beim Testen schnell identifiziert.) Mischen von ordnungsgemäß installierten Paketen und reinem setup.py develop 'd Quelle (Pip vermeiden) scheint jedoch zu funktionieren.

Wir scheinen auch in der Lage zu sein, in seltsame Situationen zu geraten, in denen ein einzelnes Namespace-beitragendes Paket auf drei verschiedene Arten installiert werden kann, manchmal alle gleichzeitig. (Wiederholte Aufrufe von pip uninstall , bei denen jeweils mehr Dateien gefunden werden, sind ebenso witzig wie unglücklich.) Die Installation von Abhängigkeiten bei Verwendung von pip install -e scheint ebenfalls inkonsistent zu sein. In den meisten Fällen haben wir ordnungsgemäß entpackte Namespaces (installiert), pth-link-Dateien (installiert, bearbeitbar installiert), und in einem Fall haben wir es irgendwie geschafft, ein komprimiertes .egg installieren, trotz zip_safe ist False für dieses abhängige Paket und es wird keine .egg -Verteilung für Pypi bereitgestellt.

Die Frustration über Namespace-Probleme erreicht ihren Höhepunkt nach dem vierten Mal, wenn eine virtuelle Umgebung neu gestartet wird. ;)

Keine Lösung, aber ich habe nur ein paar Notizen gemacht. Beim Mischen zwischen 'bearbeitbaren' Paketen, Paketen mit Namespace und normalen Paketen habe ich mehr Glück mit buildout + mr.developer.

Während der erwähnte Fixup-Hack @lelit für einige Pakete zu funktionieren scheint, bricht er auch einige Pakete / Builds für uns.

Nachdem ich ein bisschen mit der Pip-Installation und dem bearbeitbaren Modus herumgespielt hatte , kam ich auf die gleiche Idee wie

Ist dies immer noch ein Problem bei neueren Versionen von Python mit PEP420? (Lesen Sie: Würde es helfen, auf eine neuere Version von Python zu wechseln?)

Die effektive Verwendung des PEP420-Stils hat mir jetzt mehrmals geholfen, den bearbeitbaren Modus zu verwenden.

Leider hat es seine eigenen Pannen: Zum Beispiel wird find_packages setuptools nicht unterstützt , daher enthalten meine neueren Pakete den folgenden Hack:

-    packages=find_packages('src'),
+    packages=['toplevel.child.' + package
+              for package in find_packages('src/toplevel/child/')],

Niemand scheint das Hinzufügen einer -nspkg.pth für jedes bearbeitbare Paket implementiert zu haben.

Schauen Sie sich Setuptools 31 an, das diese Funktion unterstützt und auch mit PEP-420-Paketen unter Python 3.5+ koexistiert.

Für alle Neugierigen gibt es hier eine vollständige Liste, wie Namespace-Pakete in pip install , pip install -e , python setup.py install und python setup.py develop funktionieren:

https://github.com/jonparrott/namespace-pkg-tests/blob/master/table.md

tl; dr: Sie können pip install -e und python setup.py develop , solange jedes andere Paket in Ihrem Namespace mit pip installiert wurde.

Ich werde dieses Problem schließen. Es scheint, dass setuptools 31 dies für unsere Reproduktionsskripte behoben hat, und darüber hinaus kann pip hier nichts tun.

@ Jonparrott
Welche Versionen von pip und setuptools wurden verwendet, um Ergebnisse unter https://github.com/jonparrott/namespace-pkg-tests/blob/master/table.md zu erhalten ?

@dstufft Obwohl ich es zu schätzen weiß, dass es angeblich behoben ist, würde ich gerne sehen, dass die Kompatibilitätstabelle von

In den Beispielen von @jonparrott könnten die fehlgeschlagenen Fälle auf "direkte Verwendung von python setup.py install reduziert werden (mit Ausnahme der erwarteten PEP 420-Fehler in Python 2). Dies schlägt auch in Fällen fehl, in denen pip nicht beteiligt ist überhaupt (wie python setup.py install + python setup.py develop ).

Dieses Ticket war für Kombinationen von pip install . und pip install -e oder python setup.py develop .

Die Grafik, die bereits von @jonparrott gepostet wurde, python setup.py install und nicht mit pip sind.

Ich habe gerade meine Tests erneut ausgeführt und alles ist das gleiche wie ursprünglich. Ich stimme der Einschätzung von @dstufft zu - pip hat alles getan, um dies zu beheben.

@ piotr-dobrogost Der Test verwendet die neuesten Versionen von beiden. Zum jetzigen Zeitpunkt sind Pip 9.0.1 und Setuptools 34.3.2.