Próbowałem zainstalować pakiety Pythona w systemie, do którego niedawno uzyskałem dostęp. Próbowałem wykorzystać stosunkowo nowy katalog pakietów witryn w języku Python dla każdego użytkownika i nową opcję --user. (Ta opcja jest obecnie nieudokumentowana , jednak istnieje dla Pythona 2.6+; możesz zobaczyć pomoc, uruchamiając python setup.py install --help.)

Kiedy próbowałem biegać

python setup.py install --user

na każdym pobranym pakiecie zawsze otrzymywałem następujący błąd:

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

Błąd był bardzo kłopotliwy, ponieważ, jak widać, nie było dostarczaniu --prefix, --exec-prefix, --install-base, lub --install-platbaseflagi jak opcje wiersza poleceń. Zmarnowałem dużo czasu, próbując dowiedzieć się, na czym polega problem. Poniżej dokumentuję swoją odpowiedź, mając nadzieję, że oszczędzę innej biednej duszy kilku godzin golenia jaka .

Jednorazowe obejście:

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

lub

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

Zauważ, że nie ma tekstu (nawet spacji) po =.

Czy nie zapomnieć o --userflagę.

Instalowanie wielu pakietów:

Utwórz ~/.pydistutils.cfg(lub odpowiednik dla swojego systemu operacyjnego / platformy) z następującą zawartością:

[install]
prefix=

Zauważ, że nie ma tekstu (nawet spacji) po =.

Następnie uruchom niezbędne pip install --userlub python setup.py install --userpolecenia. Czy nie zapomnieć o --userflagę.

Na koniec usuń lub zmień nazwę tego pliku. Pozostawienie tego pliku obecnego spowoduje problemy podczas instalowania pakietów Pythona w całym systemie (tj. Bez --user) jako użytkownik z tym ~/.pydistutils.cfg.

Przyczyna tego problemu

Wydaje się, że jest to problem zarówno z OpenSUSE, jak i RedHat, co doprowadziło do błędu w virtualenv na tych platformach.

Błąd wynika z pliku konfiguracyjnego distutils na poziomie systemu (w moim przypadku /usr/lib64/python2.6/distutils/distutils.cfg), w którym to było

[install]
prefix=/usr/local

Zasadniczo jest to równoważne z zawsze uruchamianiem polecenia instalacji jako install --prefix=/usr/local. Musisz zmienić tę specyfikację, używając jednej z powyższych technik.

Jak zauważono w komentarzach, przyjęta odpowiedź (autorstwa @gotgenes, który prawdopodobnie ma geny) może prowadzić do nieoczekiwanych konsekwencji.

@rogeleaderr mówi: „Zauważ, że zachowanie tego pliku w ten sposób sprawi, że Python pomyśli, że / jest Twoim głównym katalogiem biblioteki Pythona, co prowadzi do kłopotliwych problemów, jeśli spróbujesz zainstalować inne nowe pakiety”.

Zamiast pisać nowy plik konfiguracyjny, jak zaleca @gotgenes, lepszą opcją jest dodanie --prefix= (bez tekstu po prawej stronie znaku równości) jako opcji w wierszu poleceń , jak w

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

Publikowanie, aby zaoszczędzić innym czas, ponieważ żadne dostępne odpowiedzi nie działały dla mnie ...

W niektórych środowiskach użycie przełącznika --target( -t) nadal spowoduje ten sam błąd. Podczas moich testów na dwóch odmianach Linuksa napotkałem ten sam problem podczas używania --prefix=parametru.

Kod:

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

Wyjaśnienie: Moje obejście, które wydaje się działać w wielu środowiskach (MacOS, Amazon Linux, Debian), polega na ustawieniu PYTHONUSERBASEzmiennej środowiskowej na lokalizację tymczasową. --force-reinstallsłuży do wyzwalania instalacji lokalnej, nawet jeśli pakiet jest już zainstalowany.

Spowoduje to skompilowanie / zainstalowanie modułu (w zależności od wersji systemu operacyjnego i Pythona) w celu: /tmp/lib/python2.7/site-packages/*

Możesz po prostu uruchomić pip install --user ., bez prefiksów argumentów.

To i tak jest lepsze, ponieważ domyślnie będzie to python3, jeśli twój pip jest skonfigurowany do korzystania z Pythona 3. (zapomniałem wejść python3 setup.pyi zainstalowałem pakiet tylko 3 pod 2.7)

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

Miałem ten sam problem. Został ukryty w środku ~/.config/pip/pip.confz:

[global]
target=/foo/bar

Taka konfiguracja została stworzona przez skrypt innej firmy bez mojej wiedzy.

Sugeruję sprawdzenie plików konfiguracyjnych pip i usunięcie target=/foo/baropcji.