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

Erstellt am 14. MĂ€rz 2011  Â·  41Kommentare  Â·  Quelle: pypa/pip

Ein bearbeitbares und regelmĂ€ĂŸig installiertes Namespace-Paket funktioniert nicht gut zusammen.

auto-locked bug

Hilfreichster Kommentar

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.

Alle 41 Kommentare

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.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen