Ich habe versucht, Python-Pakete auf einem System zu installieren, auf das ich kürzlich Zugriff hatte. Ich habe versucht, das relativ neue Site-Packages-Verzeichnis von Python pro Benutzer und die neue Option zu nutzen --user. (Die Option ist derzeit nicht dokumentiert , existiert jedoch für Python 2.6+. Sie können die Hilfe anzeigen, indem Sie sie ausführen python setup.py install --help.)

Als ich versuchte zu rennen

python setup.py install --user

Bei jedem Paket, das ich heruntergeladen habe, wurde immer der folgende Fehler angezeigt:

error: can't combine user with with prefix/exec_prefix/home or install_(plat)base

Der Fehler extrem war verwirrend , weil, wie Sie sehen können, ich war die Bereitstellung nicht die --prefix, --exec-prefix, --install-baseoder --install-platbaseFlaggen als Befehlszeilenoptionen. Ich habe viel Zeit damit verschwendet, herauszufinden, wo das Problem liegt. Ich dokumentiere meine Antwort unten in der Hoffnung, einer anderen armen Seele ein paar Stunden Yak-Rasur zu ersparen .

Einmalige Problemumgehung:

pip install --user --install-option="--prefix=" <package_name>

oder

python setup.py install --user --prefix=

Beachten Sie, dass nach dem kein Text (nicht einmal Leerzeichen) steht =.

Sie nicht vergessen , die --userFlagge.

Mehrere Pakete installieren:

Erstellen ~/.pydistutils.cfg(oder gleichwertig für Ihr Betriebssystem / Ihre Plattform) mit den folgenden Inhalten:

[install]
prefix=

Beachten Sie, dass nach dem kein Text (nicht einmal Leerzeichen) steht =.

Führen Sie dann die notwendige pip install --useroder python setup.py install --userBefehle. Sie nicht vergessen , die --userFlagge.

Entfernen Sie diese Datei oder benennen Sie sie um. Das Belassen dieser Datei führt zu Problemen bei der systemweiten Installation von Python-Paketen (dh ohne --user), wenn dieser Benutzer dies tut ~/.pydistutils.cfg.

Die Ursache für dieses Problem

Dies scheint sowohl bei OpenSUSE als auch bei RedHat ein Problem zu sein, das zu einem Fehler in virtualenv auf diesen Plattformen geführt hat.

Der Fehler stammt aus einer Distutils-Konfigurationsdatei auf Systemebene (in meinem Fall /usr/lib64/python2.6/distutils/distutils.cfg), in der diese vorhanden war

[install]
prefix=/usr/local

Grundsätzlich entspricht dies immer dem Ausführen des Installationsbefehls als install --prefix=/usr/local. Sie müssen diese Spezifikation mit einer der oben genannten Techniken überschreiben.

Wie in den Kommentaren erwähnt, kann die akzeptierte Antwort (von @gotgenes, der vermutlich Gene hat) zu unerwarteten Konsequenzen führen.

@rogeleaderr sagt: "Beachten Sie, dass Python bei der Beibehaltung dieser Datei denkt, dass / Ihr Root-Python-Bibliotheksverzeichnis ist, was zu verwirrenden Problemen führt, wenn Sie versuchen, andere neue Pakete zu installieren."

Anstatt eine neue Konfigurationsdatei zu schreiben, wie von @gotgenes empfohlen, ist es eine bessere Option, --prefix= (ohne Text rechts neben dem Gleichheitszeichen) eine Option in der Befehlszeile hinzuzufügen , wie in

$ python setup.py install --user --prefix=

Posten, um anderen Zeit zu sparen, da für mich keine verfügbaren Antworten funktionierten ...

In einigen Umgebungen tritt bei Verwendung des Schalters --target( -t) immer noch der gleiche Fehler auf. Bei meinen Tests mit zwei Linux-Varianten ist bei der Verwendung des --prefix=Parameters dasselbe Problem aufgetreten .

Code:

PYTHONUSERBASE=/tmp/ pip install --user --force-reinstall $PACKAGE

Erläuterung: Meine Problemumgehung, die in vielen Umgebungen (MacOS, Amazon Linux, Debian) zu funktionieren scheint, besteht darin, die PYTHONUSERBASEUmgebungsvariable auf einen temporären Speicherort festzulegen. --force-reinstallwird verwendet, um die lokale Installation auszulösen, auch wenn das Paket bereits installiert ist.

Dies führt dazu, dass das Modul kompiliert / installiert wird (abhängig von der Betriebssystem- und Python-Version), um: /tmp/lib/python2.7/site-packages/*

Sie können einfach ausführen pip install --user ., ohne Präfixargumente.

Dies ist ohnehin besser, da standardmäßig Python3 verwendet wird, wenn Ihr Pip für die Verwendung von Python 3 konfiguriert ist. (Ich habe die Eingabe vergessen python3 setup.pyund ein Nur-3-Paket unter 2.7 installiert.)

(Gutschrift https://stackoverflow.com/a/1550235/4364036 )

Ich hatte das gleiche Problem. Es war versteckt in ~/.config/pip/pip.conf:

[global]
target=/foo/bar

Eine solche Konfiguration wurde ohne mein Wissen von einem Skript eines Drittanbieters erstellt.

Ich schlage vor , die Pip-Konfigurationsdateien zu überprüfen und die target=/foo/barOptionen zu entfernen .