DistutilsOptionError: musi podać home lub prefix / exec-prefix - nie oba

Zazwyczaj instalowałem pakiety Pythona przez pip.

W przypadku Google App Engine muszę zainstalować pakiety w innym katalogu docelowym.

Próbowałem:

pip install -I flask-restful --target ./lib

ale zawodzi z:

musi podać home lub prefix / exec-prefix - nie oba

Jak to działa?

Czy używasz OS X i Homebrew? Strona Homebrew w języku Python https://github.com/Homebrew/brew/blob/master/docs/Homebrew-and-Python.md przedstawia znany problem z pip i obejście go.

Pracował dla mnie.

Możesz ustawić ten „pusty prefiks” jako domyślny, dodając plik ~ / .pydistutils.cfg o następującej zawartości:

[install]
prefix=

Edycja: nie używaj tej zalecanej opcji Homebrew, spowoduje to przerwanie normalnych operacji pip .

Uważam, że istnieje prostsze rozwiązanie tego problemu (Python firmy Homebrew na macOS), które nie zakłóci normalnych operacji pip.

Wszystko, co musisz zrobić, to utworzyć setup.cfgplik w katalogu głównym projektu, zwykle tam, gdzie znajduje się główny __init__.pylub wykonywalny plik py. Więc jeśli katalog główny twojego projektu to /path/to/my/project/:, utwórz tam setup.cfgplik i umieść w nim magiczne słowa:

[install]
prefix=  

OK, teraz możesz uruchomić polecenia pip dla tego folderu:

pip install package -t /path/to/my/project/  

To polecenie będzie działać z wdziękiem tylko dla tego folderu. Po prostu skopiuj setup.cfgdo innych projektów, które możesz mieć. Nie musisz pisać .pydistutils.cfgw swoim katalogu domowym.

Po zainstalowaniu modułów możesz je usunąć setup.cfg .

W systemie OSX (Mac) przy założeniu folderu projektu o nazwie / var / myproject

1. cd /var/myproject
2. Utwórz plik o nazwie setup.cfgi dodaj [install] prefix=
3. Biegać pip install <packagename> -t .

Innym rozwiązaniem * dla użytkowników Homebrew jest po prostu użycie pliku virtualenv.

Oczywiście może to i tak usunąć potrzebę katalogu docelowego - ale nawet jeśli nie, znalazłem, że --targetdziała domyślnie (jak w, bez tworzenia / modyfikowania pliku konfiguracyjnego) w środowisku wirtualnym.

* Mówię rozwiązanie; może to tylko kolejna motywacja do skrupulatnego stosowania venvów ...

Występują błędy z innymi zaleceniami dookoła --install-option="--prefix=lib". Okazało się, że jedyne, co zadziałało, to używanie w PYTHONUSERBASEsposób opisany tutaj .

export PYTHONUSERBASE=lib
pip install -I flask-restful --user

to nie jest dokładnie to samo, co --target, ale w każdym przypadku działa dla mnie.

Jak wspomniano wcześniej, jest to znany błąd występujący w pip & pythonie zainstalowanym z homebrew.

Jeśli utworzysz ~/.pydistutils.cfgplik z instrukcją „pusty prefiks”, rozwiąże to problem, ale spowoduje przerwanie normalnych operacji pip.

Dopóki ten błąd nie zostanie oficjalnie usunięty, jedną z opcji byłoby utworzenie własnego skryptu bash, który będzie obsługiwał ten przypadek:

 #!/bin/bash

 name=''
 target=''

 while getopts 'n:t:' flag; do
     case "${flag}" in
         n) name="${OPTARG}" ;;
         t) target="${OPTARG}" ;;
     esac
 done

 if [ -z "$target" ];
 then
     echo "Target parameter must be provided"
     exit 1
 fi

 if [ -z "$name" ];
 then
     echo "Name parameter must be provided"
     exit 1
 fi

 # current workaround for homebrew bug
 file=$HOME'/.pydistutils.cfg'
 touch $file

 /bin/cat <<EOM >$file
 [install]
 prefix=
 EOM
 # end of current workaround for homebrew bug

 pip install -I $name --target $target

 # current workaround for homebrew bug
 rm -rf $file
 # end of current workaround for homebrew bug

Ten skrypt opakowuje twoje polecenie i:

1. akceptuje nazwę i parametry docelowe
2. sprawdza, czy te parametry są puste
3. tworzy ~/.pydistutils.cfgplik z instrukcją „pusty prefiks”
4. wykonuje polecenie pip z podanymi parametrami
5. usuwa ~/.pydistutils.cfgplik

Ten skrypt można zmienić i dostosować do swoich potrzeb, ale masz pomysł. I pozwala na wykonywanie poleceń bez hamowania. Mam nadzieję, że to pomoże :)

Jeśli używasz virtualenv *, dobrym pomysłem może być dwukrotne sprawdzenie, which pipczy używasz.

Jeśli zauważysz /usr/local/bin/pip, że wydostałeś się ze swojego otoczenia. Ponowna aktywacja virtualenv naprawi ten problem:

VirtualEnv: $ source bin/activate

VirtualFish: $ vf activate [environ]

*: Używam virtualfish, ale zakładam, że ta wskazówka dotyczy obu.

Mam podobny problem. Używam flagi --system, aby uniknąć błędu, tak jak opisuję tutaj w innym wątku, w którym wyjaśniam konkretny przypadek mojej sytuacji. Publikuję to tutaj, spodziewając się, że może to pomóc każdemu, kto ma ten sam problem.