Pip: Die Verwendung von --target mit --editable führt zu einem "internen" Fehler

Erleben Sie diesen Fehler auch mit pip install -t dir -e git+git://github.com/shazow/urllib3.git@f088037#egg=urllib3 .

Ich bin jetzt auch auf diesen Fehler gestoßen.
Dies scheint bei jedem Paket zu passieren, wenn --target und --editable kombiniert werden:
pip ruft setup.py develop --home ... , aber --home gilt nur für setup.py install .

Am Ende fand ich heraus, dass die Verwendung der Option --src mit bearbeitbaren Paketen anstelle von --target macht, was ich will.

Vielleicht sollte --target den gleichen Effekt haben wie --src wenn --editable angegeben ist, oder es könnte dem Benutzer eine Fehlermeldung anzeigen und den Benutzer möglicherweise auf --src verweisen .

Vielleicht sollte --target den gleichen Effekt haben wie --src, wenn --editable angegeben ist

IMO würde das erwartete Verhalten die Datei easy_install.pth im Verzeichnis target erstellen / aktualisieren.

Ich habe gerade das gleiche Problem erlebt. Wie von @jezdez vorgeschlagen, umgehen , indem Sie Folgendes tun (ohne --editable zu verwenden):

git+ssh://[email protected]/some-user/some-repo.git#egg=Foo

Ich sehe hier selbst ein ähnliches Problem:

Cleaning up...
Exception:
Traceback (most recent call last):
  File "/efs/dev/bti/pip/1.3.1-build001/install/exec/2.7/lib/python/pip-1.3.1-py2.7.egg/pip/basecommand.py", line 139, in main
  status = self.run(options, args)
  File "/efs/dev/bti/pip/1.3.1-build001/install/exec/2.7/lib/python/pip-1.3.1-py2.7.egg/pip/commands/install.py", line 291, in run
    for item in os.listdir(lib_dir):
OSError: [Errno 2] No such file or directory: '/tmp/tmppjdGHI/lib/python'

Zeile 290 in pip / command / install.py lautet:

     lib_dir = home_lib(temp_target_dir)

Nach allem, was ich verfolgen kann, hat pip diesen Pfad bereits in der Zeile 1194 pip / req.py bereinigt, in der die temporäre Quelle entfernt wird.

     requirement.remove_temporary_source()

Ich kann sehen, dass die Bereinigung so bleibt, wie sie ist, aber sie mit einem vorhandenen oder try-Block umschließt, damit die Installation fortgesetzt werden kann. Betrachtet jemand das als Problem?

@tima Ich hatte das gleiche Problem mit dem lib-Verzeichnis. Pip HEAD hat dies angeblich behoben, aber zumindest unter CentOS besteht das Problem weiterhin. In diesem speziellen Fall gibt es ein lib64-Verzeichnis anstelle eines lib-Verzeichnisses.

Ich habe das gleiche Problem mit --target (aber nicht --editable ).

Hier ist mein Traceback -

Exception:
Traceback (most recent call last):
  File "/Users/beaum/homebrew/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip-1.3.1-py2.7.egg/pip/basecommand.py", line 139, in main
    status = self.run(options, args)
  File "/Users/beaum/homebrew/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pip-1.3.1-py2.7.egg/pip/commands/install.py", line 294, in run
    for item in os.listdir(lib_dir):
OSError: [Errno 2] No such file or directory: '/var/folders/00/1hyxr000h01000cxqpysvccm0063vq/T/tmpc_E_Bl/lib/python'

+1,

 Herunterladen von PyYAML-3.10.tar.gz (241 KB): 241 KB heruntergeladen
 Ausführen von setup.pygg_info für das Paket pyyaml
 Überspringen der Cython-Erweiterung 'ext / _yaml.c' (aktuell)
 Gesammelte Pakete installieren: krcore, sympy, pyparsing, pyyaml
 Ausführen von setup.py für krcore entwickeln
 Verwendung: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
 oder: -c --help [cmd1 cmd2 ...]
 oder: -c --help-Befehle
 oder: -c cmd --help
 Fehler: Option --home nicht erkannt
 Vollständige Ausgabe des Befehls / usr / bin / python -c "import setuptools; __file __ = '/ tmp / krapp / src / krcore / setup.py'; exec (compile (open (__ file __). Read (). Replace ('\ r \ n ',' \ n '), __file__,' exec ')) "entwickle --no-deps --home = / tmp / tmpvKaRYp:
 Verwendung: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
 oder: -c --help [cmd1 cmd2 ...]
 oder: -c --help-Befehle
 oder: -c cmd --help
 Fehler: Option --home nicht erkannt
 ----------------------------------------
 Aufräumen...
 Befehl / usr / bin / python -c "setuptools importieren; __file __ = '/ tmp / krapp / src / krcore / setup.py'; exec (compile (open (__ file __). Read (). Replace ('\ r \ n ',' \ n '), __file__,' exec ')) "Entwicklung --no-deps --home = / tmp / tmpvKaRYp fehlgeschlagen mit Fehlercode 1 in / tmp / krapp / src / krcore

Ich erhalte die 'Fehler: Option --home nicht erkannt', wenn ich --target mit -r (--requirements) verwende.

: +1:

Folgende Problemumgehung von @jezdez verursacht:
Fehler: muss entweder Home oder Präfix / Exec-Präfix angeben - nicht beide

Die Optionen --editable und --target funktionieren nicht zusammen

Ich habe das gleiche Problem getroffen ...
Ich versuche, mit pip Python-Pakete an einem benutzerdefinierten Speicherort (nicht an einem virtuellen Env) zu installieren, und ich benötige eines davon (das, an dem ich arbeite), um bearbeitet werden zu können.

Dies hängt wahrscheinlich mit https://github.com/pypa/setuptools/issues/392 zusammen

Und da ein Pip-Befehl sowohl setup.py develop (für bearbeitbares Paket) als auch setup.py install (Abhängigkeiten) auslösen kann, besteht die einzige (sehr hässliche) Problemumgehung darin, zwei Befehle auszugeben:

• eine für pkg mit --no-deps
• eine nur für Abhängigkeiten (kein einfacher Weg hier ...)

Es wäre viel sauberer, wenn andere Pip-Befehlszeilenoptionen nicht geändert werden müssten, unabhängig davon, ob --editable wird oder nicht.
Ich denke, es gibt zwei Möglichkeiten, um dies zum Laufen zu bringen:

• Setuptools unterstützen --home dh. Behebung von https://github.com/pypa/setuptools/issues/392. wahrscheinlich schwierig, die Details dieses Problems zu lesen?
• Pip abstrakte Setuptools-Details haben und das Verhalten von --target unterschiedlich implementieren, je nachdem, ob setup.py develop oder setup.py install aufgerufen wird. vielleicht einfacher?

Pip abstrakte Setuptools-Details haben und das Verhalten von --target unterschiedlich implementieren, je nachdem, ob setup.py develop oder setup.py install aufgerufen wird. vielleicht einfacher?

Die größte Schwierigkeit bei dieser Option besteht darin, dass pip daran arbeitet, die Details des Build-Systems (Setuptools) zu abstrahieren, sodass spezielle Problemumgehungen für Setuptools-Probleme diesem Ziel entgegenwirken.

Am Ende habe ich es geschafft, mit --prefix und ohne benutzerdefinierte --install-option zu tun, was ich wollte, sodass ich endlich die gleichen Optionen verwenden kann, unabhängig davon, ob ich --editable oder nicht .

Allerdings musste ich mein vorhandenes (Debian-) Layout irgendwie an den Pip-Standard (Site-Pakete) anpassen, da es keine Pip-Option gibt, um das Layout anzugeben ...

Vielleicht eine Funktion, die Sie hinzufügen sollten?

@ Xavfernandez

Dies erfordert ein --target option Label.

Könnte jemand bitte mitteilen, was die beste Problemumgehung ist, um die Optionen -e und -t zu verwenden? Schlagen Sie vor, distutils zu verwenden, da es die Option '--home' unterstützt?

irgendwelche Neuigkeiten?

Ich verwende immer noch --editable mit --prefix (anstelle von --target ), was die Arbeit für mich erledigt. Aber ich stecke wegen des Unterschieds zwischen --prefix und --target bei pip <9.0.0 fest. Weitere Informationen finden Sie unter https://github.com/pypa/pip/issues/4243

Wenn Sie die Option --prefix anstelle von --target verwenden möchten, muss das PYTHONPATH (das auf das zu erstellende Site-Paket-Verzeichnis verweist) korrekt eingestellt sein, bevor Sie pip -t . --prefix myprefix aufrufen können

Schließen, um eine Reihe verwandter Probleme auf ein einziges Problem zu verschieben: # 4390.

Ich möchte hinzufügen, dass dies ein Problem für Google Appengine-Entwickler ist, die ihre Abhängigkeiten in einem Verzeichnis im App-Stammverzeichnis installieren müssen, aber im Rahmen eines QS-Prozesses auch eine bearbeitbare Abhängigkeit in einer lokalen Kasse bereitstellen müssen. Wie es sitzt, müsste das bearbeitbare manuell verknüpft werden, was umständlich ist.

Dieser Thread wurde automatisch gesperrt, da nach dem Schließen keine aktuellen Aktivitäten stattgefunden haben. Bitte öffnen Sie eine neue Ausgabe für verwandte Fehler.