pip instaluje się w globalnych pakietach witryn zamiast virtualenv

Użycie pip3do zainstalowania pakietu w a virtualenvpowoduje, że pakiet zostanie zainstalowany w globalnym folderze pakietów lokacji zamiast w folderze virtualenv. Oto jak skonfigurowałem Python3 i virtualenv na OS X Mavericks (10.9.1):

Zainstalowałem Python3 za pomocą Homebrew:

ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)"
brew install python3 --with-brewed-openssl

Zmieniono $PATHzmienną w .bash_profile; dodał następujący wiersz:

export PATH=/usr/local/bin:$PATH

Uruchamianie which python3zwraca /usr/local/bin/python3(po ponownym uruchomieniu powłoki).

Uwaga: which python3nadal zwraca / usr/bin/pythonchociaż.

Zainstalowano virtualenvprzy użyciu pip3:

pip3 install virtualenv

Następnie utwórz nowy virtualenvi aktywuj go:

virtualenv testpy3 -p python3
cd testpy3
source bin/activate

Uwaga: jeśli nie określę -p python3, pip będzie brakować w folderze bin w virtualenv.

Uruchomione which pipi which pip3oba zwracają folder virtualenv:

/Users/kristof/VirtualEnvs/testpy3/bin/pip3

Teraz, kiedy próbuję zainstalować np. Markdown przy użyciu pip w aktywowanym virtualenv, pip zainstaluje się w globalnym folderze pakietów witryn zamiast w folderze pakietów witryn w virtualenv.

pip install markdown

pip listZwroty biegowe :

Markdown (2.3.1)
pip (1.4.1)
setuptools (2.0.1)
virtualenv (1.11)

Zawartość /Users/kristof/VirtualEnvs/testpy3/lib/python3.3/site-packages:

__pycache__/
_markerlib/
easy_install.py
pip/
pip-1.5.dist-info/
pkg_resources.py
setuptools/
setuptools-2.0.2.dist-info/

Zawartość /usr/local/lib/python3.3/site-packages:

Markdown-2.3.1-py3.3.egg-info/
__pycache__/
easy-install.pth
markdown/
pip-1.4.1-py3.3.egg/
setuptools-2.0.1-py3.3.egg
setuptools.pth
virtualenv-1.11-py3.3.egg-info/
virtualenv.py
virtualenv_support/

Jak widać, globalny folder pakietów witryn zawiera Markdown, a folder virtualenv nie.

Uwaga: miałem wcześniej zainstalowane Python2 i Python3 na innej maszynie wirtualnej (postępowałem zgodnie z tymi instrukcjami) i miałem ten sam problem z Pythonem3; instalacja pakietów w virtualenv opartym na Pythonie2 działała jednak bez zarzutu.

Wszelkie wskazówki, podpowiedzi… będą bardzo mile widziane.

Zabawne, że o tym wspomniałeś, miałem dokładnie ten sam problem. W końcu to rozwiązałem, ale nadal nie jestem pewien, co go spowodowało.

Spróbuj sprawdzić swoje bin/pipi bin/activateskrypty. W bin/pip, spojrzenie na shebang. Czy to jest poprawne? Jeśli nie, popraw to. Następnie online ~ 42w swoim bin/activate, sprawdź, czy ścieżka virtualenv jest prawidłowa. Będzie wyglądać mniej więcej tak

VIRTUAL_ENV="/Users/me/path/to/virtual/environment"

Jeśli tak się stało, należy usunąć go deactivate, a następnie . bin/activate, jeśli nasz wspólny problem, miał taką samą przyczynę, to powinno działać. Jeśli nadal nie jest, i tak jesteś na dobrej drodze. Przeszedłem przez tę samą procedurę rozwiązywania problemów, co ty, which pippowtarzając w kółko, śledząc stos itp.

Upewnij się, że to absolutnie

/Users/kristof/VirtualEnvs/testpy3/bin/pip3

jest tym, czego chcesz i nie odnosi się do innego projektu testowego o podobnej nazwie (miałem ten problem i nie mam pojęcia, jak to się zaczęło. Podejrzewam, że działa wiele virtualenvów w tym samym czasie).

Jeśli nic z tego nie zadziała, może być tymczasowym rozwiązaniem, jak powiedział Joe Holloway,

Po prostu uruchom pip virtualenv z pełną ścieżką (tj. Nie polegaj na wyszukiwaniu ścieżki wykonywalnej) i nie musisz nawet aktywować środowiska. To zrobi właściwą rzecz.

Może nie jest idealny, ale powinien działać w mgnieniu oka.

Link do mojego pierwotnego pytania:

VirtualEnv / Pip próbuje zainstalować pakiety globalnie

Dla mnie to nie był problem z pipem czy virtualenvem. To był problem z Pythonem. Ustawiłem moją $ PYTHONPATH ręcznie w ~ / .bash_profile (lub ~ / .bashrc) po przejściu kilku poradników online. To ręcznie ustawione $ PYTHONPATH było dostępne w virtualenv, ponieważ prawdopodobnie powinno być dozwolone.

Ponadto add2virtualenvz jakiegoś powodu nie dodawałem ścieżki projektu do mojej $ PYTHONPATH w ramach virtualenv.

Tylko rozwidlające się ścieżki dla tych, którzy wciąż mogą utknąć! Twoje zdrowie!

Miałem ten sam problem, rozwiązałem go usuwając katalog venv i odtwarzając go!

deactivate (if venv is activated first deactivate it)
rm -rf venv
virtualenv -p python3 venv
. ENV/bin/activate
pip3 install -r requirements.txt

Teraz wszystko działa jak urok.

Ja też miałem ten problem. Wywołanie pip install <package_name>z /binkatalogu w moim środowisku wirtualnym Python 3.3 na moim Macu Mavericks spowodowało zainstalowanie pakietu Pythona w katalogu pakietów witryny globalnej Pythona 2.7. Stało się tak pomimo faktu, że moja $ PATH zaczęła się od katalogu zawierającego pip. Dziwne. To się nie dzieje w CentOS. Dla mnie rozwiązaniem było wezwanie pip3zamiast pip. Kiedy miałem zainstalowany PIP w środowisku wirtualnym poprzez ez_setup , trzy „pip” wykonywalne został zainstalowany w /binkatalogu - pip, pip3i spowodował pakiet Python być zainstalowany poprawnie do lokalnego katalogu site-packages. Powołaniepip3.3 . Co ciekawe, wszystkie trzy pliki były dokładnie takie same. Powołaniepip3 install <package_name>pip z pełną ścieżką dostępu do środowiska wirtualnego również działało poprawnie. Chciałbym wiedzieć, dlaczego mój Mac nie używa $ PATH tak, jak bym tego oczekiwał.

Pierwszą rzeczą do sprawdzenia jest to, która lokalizacja pip jest rozwiązywana na:

which pip

jeśli jesteś w virtualenv, możesz oczekiwać, że da ci to coś takiego:

/path/to/virtualenv/.name_of_virtualenv/bin/pip

Jednak może się zdarzyć, że z jakiegoś powodu rozwiązuje się to w systemie pip. Na przykład możesz zobaczyć to z poziomu swojego virtualenv (to jest złe):

/ usr / local / bin / pip (lub cokolwiek, czego nie ma w Twojej ścieżce virtualenv).

Aby rozwiązać ten problem, sprawdź swój pipconfig w:

~/.pipconf
~/.conf/pip
/etc/pip.conf

i upewnij się, że nic nie wymusza twojej ścieżki Pythona lub ścieżki pip (to naprawiło to dla mnie).

Następnie spróbuj uruchomić nowy terminal i odbuduj swój virtualenv (usuń i utwórz go ponownie)

Napotkałem ten sam problem podczas instalowania pakietu Pythona z poziomu virtualenv. Przyczyna w moim przypadku była inna. Z poziomu virtualenv (z przyzwyczajenia na Ubuntu) robiłem:

sudo easy_install -Z <package>

To spowodowało, że bin / pip shebang został zignorowany i użył pythona innego niż virtualenv roota, aby zainstalować go w globalnych pakietach witryn. Ponieważ mamy środowisko wirtualne, powinniśmy zainstalować pakiet bez "sudo"

Natknąłem się na ten sam problem w Manjaro. Stworzyłem środowisko wirtualne za pomocą, python3 -m ven venva następnie aktywowałem za pomocą source venv/bin/actiave. which pythoni which pipoba wskazywały na prawidłowe pliki binarne w virtualenv, jednak nie byłem w stanie zainstalować go w virtualenv, nawet używając pełnej ścieżki plików binarnych. Okazało się, że kiedy odinstalowałem pakiet python-pip z sudo pacman -R python-pip python-reportlab(musiałem dołączyć reportlab, aby spełnić zależności), wszystko zaczęło działać zgodnie z oczekiwaniami. Nie wiem dlaczego, ale jest to prawdopodobnie spowodowane podwójną instalacją, w której pakiet systemowy ma pierwszeństwo.

Miałem ten sam problem na macOS z zainstalowanym Pythonem 2 i 3.

Ponadto miałem aliasy wskazujące na python3 i pip3 w moim .bash_profile.

alias python=/usr/local/bin/python3
alias pip=/usr/local/bin/pip3

Usunięcie aliasów i odtworzenie wirtualnego środowiska env przy użyciu python3 -m venv venvrozwiązało problem.

Miałem podobny problem po aktualizacji do pip==8.0.0. Musiałem uciekać się do debugowania pip, aby wyśledzić złą ścieżkę.

Jak się okazuje, mój katalog profilu zawierał plik konfiguracyjny distutils z kilkoma pustymi wartościami ścieżek. Powodowało to, że wszystkie pakiety były instalowane w tym samym katalogu głównym zamiast w odpowiednim środowisku wirtualnym (w moim przypadku /lib/site-packages).

Nie jestem pewien, jak plik konfiguracyjny się tam dostał lub jak miał puste wartości, ale zaczął się po aktualizacji pip.

Na wypadek, gdyby ktoś inny natknął się na ten sam problem, po prostu usunięcie pliku ~/.pydistutils.cfg(lub usunięcie pustej ścieżki konfiguracyjnej) rozwiązało problem w moim środowisku, ponieważ pip powrócił do domyślnej konfiguracji rozproszonej.

Przejdź do katalogu bin w swoim wirtualnym środowisku i napisz w ten sposób:

./pip3 install <package-name>

Spotkałem się dzisiaj z tym samym problemem. Po prostu ponownie zainstalowałem pip globalnie z sudo easy_install pip(OSX / Max), a następnie ponownie utworzyłem virtualenv z sudo virtualenv nameOfVEnv. Następnie po aktywacji nowego virtualenv pippolecenie działało zgodnie z oczekiwaniami.

Wydaje mi się, że nie użyłem sudogo przy pierwszym utworzeniu virtualenv i może to być powód, dla którego nie miałem dostępu pipz poziomu virtualenv, udało mi się uzyskać dostęp pip2przed tą poprawką, co było dziwne.

Oto kilka praktyk, które mogą uniknąć bólu głowy podczas korzystania ze środowisk wirtualnych:

• Utwórz folder dla swoich projektów.
• Utwórz projekty Virtualenv w tym folderze.
• Po aktywacji środowiska projektu nigdy nie używaj „ pakietu instalacyjnego sudo pip ”.
• Po zakończeniu pracy zawsze „ dezaktywuj ” swoje środowisko.
• Unikaj zmiany nazwy folderu projektu.

Aby lepiej przedstawić te praktyki, oto symulacja:

tworzenie folderu dla twoich projektów / środowisk

$ mkdir venv

tworzenie środowiska

$ cd venv/ 

$ virtualenv google_drive
New python executable in google_drive/bin/python
Installing setuptools, pip...done.

aktywizujące środowisko

$ source google_drive/bin/activate

instalowanie pakietów

(google_drive) $ pip install PyDrive
Downloading/unpacking PyDrive
Downloading PyDrive-1.3.1-py2-none-any.whl
...
...
...    
Successfully installed PyDrive PyYAML google-api-python-client oauth2client six uritemplate httplib2 pyasn1 rsa pyasn1-modules
Cleaning up...

pakiet dostępny w środowisku

(google_drive) $ python
Python 2.7.6 (default, Oct 26 2016, 20:30:19) 
[GCC 4.8.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>> import pydrive.auth
>>>  
>>> gdrive = pydrive.auth.GoogleAuth()
>>>

dezaktywuj środowisko

(google_drive) $ deactivate 

$ 

pakiet NIEDOSTĘPNY poza środowiskiem

(google_drive) $ python
Python 2.7.6 (default, Oct 26 2016, 20:32:10) 
[GCC 4.8.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>> import pydrive.auth
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named pydrive.auth
>>> 

Uwagi:

Dlaczego nie sudo?

Virtualenv tworzy dla Ciebie zupełnie nowe środowisko, definiując $ PATH oraz kilka innych zmiennych i ustawień. Korzystając z pakietu instalacyjnego sudo pip , uruchamiasz Virtualenv jako root , uciekając przed całym utworzonym środowiskiem, a następnie instalując pakiet w globalnych pakietach lokacji, a nie w folderze projektu, w którym masz środowisko wirtualne, chociaż aktywowały środowisko.

Jeśli zmienisz nazwę folderu swojego projektu (jak wspomniano w zaakceptowanej odpowiedzi) ...

... będziesz musiał dostosować niektóre zmienne z niektórych plików w katalogu bin twojego projektu.

Na przykład:

bin / pip, linia 1 (She Bang)

bin / aktywuj, wiersz 42 (VIRTUAL_ENV)

Miałem ten problem. Okazało się, że w jednej z moich nazw folderów była spacja, która spowodowała problem. Usunąłem spację, skasowałem i przywróciłem za pomocą venv i wszystko było w porządku.

Ten problem występuje podczas tworzenia instancji virtualenv, a następnie zmiany nazwy folderu nadrzędnego.

Żadne z powyższych rozwiązań nie zadziałało.

Mój venv był aktywny. pip -Vi which pippodał mi poprawną ścieżkę virtualenv, ale kiedy pip installwyłączyłem pakiety z aktywowanym venv, mój pip freezepozostał pusty.

Wszystkie zmienne środowiskowe też były poprawne.

W końcu właśnie zmieniłem pip i usunąłem virtualenv:

easy_install pip==7.0.2

pip install pip==10

sudo pip uninstall virtualenv

Zainstaluj ponownie venv:

sudo pip install virtualenv

Utwórz venv:

python -m virtualenv venv_name_here

I wszystkie pakiety zostały ponownie poprawnie zainstalowane w moim venv.

Po utworzeniu środowiska wirtualnego spróbuj użyć pip znajdującego się w yourVirtualEnvName \ Scripts

Powinien zainstalować pakiet wewnątrz Lib \ site-packages w twoim środowisku wirtualnym

Ja też miałem ten problem. Wywołanie sudo pip installspowodowało, że pakiety Pythona zostały zainstalowane w globalnym katalogu pakietów witryny, a wywoływanie pip installdziałało dobrze. Więc nie używaj sudo w virtualenv.

Ten sam problem. Python3.5 i pip 8.0.2 zainstalowane z systemu Linuxrpm .

Nie znalazłem pierwotnej przyczyny i nie mogę udzielić właściwej odpowiedzi. Wygląda na to, że istnieje wiele możliwych przyczyn.

Mam jednak nadzieję, że będę mógł pomóc w podzieleniu się moimi obserwacjami i obejściem.

1. pyvenv z --system-site-packages

   • ./binnie zawiera pip, pipjest dostępny w pakietach witryny systemu
   • pakiety są instalowane globalnie ( BŁĄD? )

2. pyvenv bez --system-site-packages

   • pipzostanie zainstalowany ./bin, ale jest to inna wersja (zensurepip )
   • pakiety są instalowane w środowisku wirtualnym ( OK )

Oczywiste obejście problemu pyvenvz --system-site-packages:

• utwórz go bez rozszerzenia --system-site-packages opcji
• zmień include-system-site-packages = falsena truew pyvenv.cfgpliku

Warto też sprawdzić, czy nie zmodyfikowałeś w jakiś sposób ścieżki do swojego virtualenv.

W takim przypadku pierwsza linia bin/pip(i reszta plików wykonywalnych) miałaby niepoprawną ścieżkę.

Możesz edytować te pliki i naprawić ścieżkę lub usunąć i ponownie zainstalować plik virtualenv.

Dla Pythona 3ers

Spróbuj zaktualizować. Miałem dokładnie ten sam problem i wypróbowałem odpowiedź Chasesa, jednak bez powodzenia. Najszybszym sposobem na zreformowanie tego jest aktualizacja wersji Python Minor / Patch, jeśli to możliwe. Zauważyłem, że korzystam z 3.5.1 i zaktualizowałem do 3.5.2. Pyvenv znów działa.

Zdarzyło mi się to, gdy utworzyłem virtualenv w złej lokalizacji. Pomyślałem wtedy, że mogę przenieść katalog w inne miejsce bez żadnego znaczenia. To miało znaczenie.

mkdir ~/projects
virtualenv myenv
cd myenv
git clone [my repository]

O cholera, zapomniałem wejść na cd projectsprzed utworzeniem virtualenv i sklonowaniem rep. No cóż, jestem zbyt leniwy, by niszczyć i odtwarzać. Po prostu przeniosę katalog bez żadnych problemów.

cd ~
mv myenv projects
cd projects/myenv/myrepo
pip install -r requirements

Nie, chce więcej uprawnień, co? Myślałem, że to dziwne, ale SUDO AWAY! Następnie zainstalował pakiety w lokalizacji globalnej.

Lekcja, której się nauczyłem, brzmiała, po prostu usuń katalog virtualenv. Nie ruszaj się.

Miałem ten problem po zainstalowaniu Divio: w jakiś sposób zmienił moją ścieżkę lub środowisko, ponieważ uruchamia terminal.

Rozwiązaniem w tym przypadku było po prostu zrobienie tego, source ~/.bash_profileco powinno być już skonfigurowane, aby wrócić do pierwotnego stanu pyenv / pyenv-virtualenv.

W jakiś sposób plik setup.cfg z prefiksem = "" w folderze projektu

uruchomienie pip install na virtualenv poza folderem projektu działało, więc od wewnątrz mówiło pipowi, aby użył pustego prefiksu, który domyślnie to „/”

usunięcie pliku naprawiło to

Miałem ten problem i po wypróbowaniu wszystkich powyższych rozwiązań po prostu usunąłem wszystko i zacząłem od nowa.

W moim przypadku użyłem sudo do stworzenia jednego z folderów, w którym istniało środowisko wirtualne, a sudo nadało uprawnienia rootowi

Byłem bardzo wkurzony! Ale zadziałało!

Z jakiegoś powodu muszę użyć „sudo” do instalowania pakietów przez pip w moim systemie ubuntu. To powoduje, że pakiety są instalowane w globalnych pakietach lokacji. Umieszczam to tutaj dla każdego, kto może zmierzyć się z tym problemem w przyszłości.

Miałem dokładnie problem z tytułu i rozwiązałem go. Pip zaczął instalować się w pakietach witryn venv po wyczyszczeniu mojej PATH: na samym początku miał ścieżkę do mojego lokalnego katalogu ~ / bin.

Tak więc moja rada: dokładnie sprawdź swoje zmienne środowiskowe pod kątem "śmieci" lub niestandardowych rzeczy. Niestety virtualenv może być na nie wrażliwy.

Powodzenia!

Krótka odpowiedź brzmi: uruchom polecenie virtualenv z parametrem „—no-site-packages”.

Długa odpowiedź z wyjaśnieniem: -

Więc po bieganiu tu i tam i przejściu przez wiele wątków stwierdziłem, że sam problem. Powyższe odpowiedzi dały pomysł, ale chciałbym jednak wszystko powtórzyć.

• Problem polega na tym, że nawet jeśli aktywujesz środowisko, odnosi się ono do środowiska systemowego ze względu na sposób, w jaki stworzyliśmy virtualenv.

• kiedy uruchomimy polecenie virtualenv env -p python3 , zainstaluje on virtualenv, ale nie utworzy no-global - site-packages.txt.

• Z tego powodu, gdy aktywujesz środowisko za pomocą polecenia aktywuj źródło, ten plik o nazwie site.py (nazwa może być inna, po prostu zapomniałem), który uruchamia się i sprawdza, czy ten plik nie istnieje, nie doda ścieżki env do sys.path i używaj systemów Python.

• Aby naprawić ten problem, po prostu uruchom virtualenv z dodatkowym parametrem —no-site-packages, który utworzy ten plik, a kiedy aktywujesz środowisko, doda twoją niestandardową ścieżkę do środowiska w zmiennej PATH, aby było dostępne.

Wiele dobrych dyskusji powyżej, ale zostały użyte przykłady virtualenv. Ponieważ „conda” jest teraz zalecanym narzędziem do zarządzania virtualenv, podsumowałem kroki w celu uruchomienia pip w conda env w następujący sposób.

Użyję py36r jako nazwy env, a / opt / conda / envs to prefiks do envs):

$ source /opt/conda/etc/profile.d/conda.sh # skip if already done 
$ conda activate py36r
$ pip  install pkg_xyz
$ pip  list | grep pkg_xyz

Zauważ, że wykonywany pip powinien być w /opt/conda/envs/py36r/bin/pip(nie /opt/conda/bin/pip).

Alternatywnie możesz po prostu uruchomić to bez aktywacji warunku

$ /opt/conda/envs/py36r/bin/pip

Ponadto, jeśli instalujesz przy użyciu conda, możesz zainstalować bez aktywacji:

$ conda install -n py36r pkg_abc ...

WINDOWS

Dla mnie rozwiązaniem nie było zastosowanie mkvirtualenv, ale:

python -m venv path/to/your/virtualenv

workon działa poprawnie.

while in virtualenv: pip -Vpokazuje ścieżkę virtualenv do pip

Z tym problemem też się spotkałem, męczyło mnie to długo, dopóki nie rozwiązałem go według metody @Chase Ries.

Kluczem do rozwiązania problemu jest ：

Spróbuj sprawdzić swoje bin/pipi bin/activateskrypty. W bin/pip, spojrzenie na shebang. Czy to jest poprawne? Jeśli nie, popraw to. Następnie online ~ 42w swoim bin/activate, sprawdź, czy ścieżka virtualenv jest prawidłowa. Będzie wyglądać mniej więcej tak

VIRTUAL_ENV="/Users/me/path/to/virtual/environment"

Jeśli tak się stało, należy usunąć go deactivate, a następnie . bin/activate, jeśli nasz wspólny problem, miał taką samą przyczynę, to powinno działać.

Poniżej wyjaśnię szczegółowo ten proces w Ubuntuśrodowisku, to samo dotyczy WindowsiMacOS .

Sens tego zdania jest to, że musimy sprawdzić, czy pierwszy wiersz #!/path/pythonz bin/pippliku w środowisku wirtualnym jest poprawna.

Jak pierwotnie pokazano w moim pliku:

#!/home/banni/dai/.venv/bin/python3

Uruchom pipw terminalu （ścieżka bezwzględna） ：

/home/banni/dai/.venv/bin/pip

Znajdzie błąd ：

bash: ./pip: /home/banni/dai/.venv/bin/python3: bad interpreter: No such file or directory

Teraz jestem zdezorientowany, dlaczego nie mogę tego znaleźć python3, ponieważ python3istnieje w folderze, w .venv/binktórym znajduje się środowisko wirtualne.

Sprawdzam bezwzględną ścieżkę do folderu .venv/bin. Po wykonaniu pwdpolecenia wyświetla:

/home/banni/Research/dai/.venv/bin

Uważnie obserwuj, czy .venvzmieniła się ścieżka do folderu. Zmień pierwszą linię /bin/pippliku na

#!/home/banni/Research/dai/.venv/bin/python3

W ten sam sposób sprawdź i zmodyfikuj bin/activateplik.

Zmieniłem VIRTUAL_ENV="/home/banni/dai/.venv"sięVIRTUAL_ENV="/home/banni/Research/dai/.venv"

W tym momencie, po aktywowaniu środowiska wirtualnego, pippolecenie można wykonać normalnie.

Dla mnie powodem tego problemu jest zmiana ścieżki folderu, w którym znajduje się środowisko wirtualne (tajny problem, który pozostawiono, gdy foldery były wcześniej organizowane).

Jednak ze względu na zmianę lokalizacji folderu, w którym znajduje się środowisko wirtualne, może wystąpić wiele błędów ścieżek, więc najłatwiej jest przywrócić folder, w którym znajduje się środowisko wirtualne, do pierwotnej lokalizacji.