Użycie pip3
do zainstalowania pakietu w a virtualenv
powoduje, ż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 $PATH
zmienną w .bash_profile
; dodał następujący wiersz:
export PATH=/usr/local/bin:$PATH
Uruchamianie which python3
zwraca /usr/local/bin/python3
(po ponownym uruchomieniu powłoki).
Uwaga: which python3
nadal zwraca / usr/bin/python
chociaż.
Zainstalowano virtualenv
przy użyciu pip3
:
pip3 install virtualenv
Następnie utwórz nowy virtualenv
i 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 pip
i which pip3
oba 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 list
Zwroty 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.
źródło
pip3
?). Samo w sobie może nie być złe, ale powinieneś być świadomy, jeśli tak jest.Odpowiedzi:
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/pip
ibin/activate
skrypty. Wbin/pip
, spojrzenie na shebang. Czy to jest poprawne? Jeśli nie, popraw to. Następnie online ~42
w swoimbin/activate
, sprawdź, czy ścieżka virtualenv jest prawidłowa. Będzie wyglądać mniej więcej takVIRTUAL_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 pip
powtarzając w kółko, śledząc stos itp.Upewnij się, że to absolutnie
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,
Może nie jest idealny, ale powinien działać w mgnieniu oka.
Link do mojego pierwotnego pytania:
VirtualEnv / Pip próbuje zainstalować pakiety globalnie
źródło
#!/usr/local/bin/python3.3
zamiast tego ustawiono#!/Users/kristof/VirtualEnvs/testpy3/bin/python3.3
. Zmieniłem to, aktywowałem virtualenv i zainstalowałem pakiet Markdown. Pip jest teraz instalowany w folderze virtualenv site-packages zamiast w globalnym.activate
skrypt był w porządku, ale uwaga , wszystkie tepip*
skrypty ieasy_install*
skrypty mają złą shebang. Wszystkie muszą zostać naprawione ręcznie. Nie mogłem ich naprawić przez ponowną instalację pip lub coś w tym rodzaju. Ponadto wyjaśnienie obejścia problemu Joe Hollowaya: problem nie polega na tym, że powłoka wyszukuje pip, ale w tym, że pip wyraźnie określa niewłaściwy Python. Dlatego musisz samodzielnie określić pythona, na przykład:$ ~/.virtualenvs/venv/bin/python ~/.virtualenvs/venv/bin/pip --version
--relocatable
moim env, a wiersz 42 jest zły, wygląda na to,--relocatable
że nie wykonał tego dobrze.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
add2virtualenv
z 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!
źródło
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.
źródło
pip3
podczas virtualenv domyślnie używane python2 zatem stosującpip
zamiastpip3
. Sprawdziłem,bin
aby znaleźć niepip3
. Użycievirtualenv -p python3 venv
rozwiązało problem.Ja też miałem ten problem. Wywołanie
pip install <package_name>
z/bin
katalogu 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ącegopip
. Dziwne. To się nie dzieje w CentOS. Dla mnie rozwiązaniem było wezwaniepip3
zamiastpip
. Kiedy miałem zainstalowany PIP w środowisku wirtualnym poprzez ez_setup , trzy „pip” wykonywalne został zainstalowany w/bin
katalogu -pip
,pip3
i 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ł.źródło
Pierwszą rzeczą do sprawdzenia jest to, która lokalizacja pip jest rozwiązywana na:
jeśli jesteś w virtualenv, możesz oczekiwać, że da ci to coś takiego:
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):
Aby rozwiązać ten problem, sprawdź swój pipconfig w:
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)
źródło
/etc/pip.conf
! Miałem podobny problem i po wielu debugowaniu doszedłem do wniosku, że ktoś źle skonfigurował system, nad którym pracowałem, bawiąc się tym plikiem.which pip
nadal podawał mi poprawną ścieżkę!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:
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"
źródło
Natknąłem się na ten sam problem w Manjaro. Stworzyłem środowisko wirtualne za pomocą,
python3 -m ven venv
a następnie aktywowałem za pomocąsource venv/bin/actiave
.which python
iwhich pip
oba 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 zsudo 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.źródło
python-pip
przez pamac i pip virtualenv nadal działał poprawnie. Nie jestem pewien, co się dzieje, ale zgadzam się z twoją oceną problemu z podwójną instalacją.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
.Usunięcie aliasów i odtworzenie wirtualnego środowiska env przy użyciu
python3 -m venv venv
rozwiązało problem.źródło
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.źródło
[install]\nprefix=
Przejdź do katalogu bin w swoim wirtualnym środowisku i napisz w ten sposób:
źródło
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 zsudo virtualenv nameOfVEnv
. Następnie po aktywacji nowego virtualenvpip
polecenie działało zgodnie z oczekiwaniami.Wydaje mi się, że nie użyłem
sudo
go przy pierwszym utworzeniu virtualenv i może to być powód, dla którego nie miałem dostępupip
z poziomu virtualenv, udało mi się uzyskać dostęppip2
przed tą poprawką, co było dziwne.źródło
virtualenv
go było ponownie uruchomićOto kilka praktyk, które mogą uniknąć bólu głowy podczas korzystania ze środowisk wirtualnych:
Aby lepiej przedstawić te praktyki, oto symulacja:
tworzenie folderu dla twoich projektów / środowisk
tworzenie środowiska
$ cd venv/ $ virtualenv google_drive New python executable in google_drive/bin/python Installing setuptools, pip...done.
aktywizujące środowisko
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
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?
Jeśli zmienisz nazwę folderu swojego projektu (jak wspomniano w zaakceptowanej odpowiedzi) ...
źródło
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.
źródło
Ten problem występuje podczas tworzenia instancji virtualenv, a następnie zmiany nazwy folderu nadrzędnego.
źródło
Żadne z powyższych rozwiązań nie zadziałało.
Mój venv był aktywny.
pip -V
iwhich pip
podał mi poprawną ścieżkę virtualenv, ale kiedypip install
wyłączyłem pakiety z aktywowanym venv, mójpip freeze
pozostał 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:
Utwórz venv:
I wszystkie pakiety zostały ponownie poprawnie zainstalowane w moim venv.
źródło
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
źródło
Ja też miałem ten problem. Wywołanie
sudo pip install
spowodowało, że pakiety Pythona zostały zainstalowane w globalnym katalogu pakietów witryny, a wywoływaniepip install
działało dobrze. Więc nie używaj sudo w virtualenv.źródło
sudo su
po którym<venv>/bin/activate
następujepip install
.Ten sam problem. Python3.5 i pip 8.0.2 zainstalowane z systemu Linux
rpm
.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.
pyvenv
z--system-site-packages
./bin
nie zawierapip
,pip
jest dostępny w pakietach witryny systemupyvenv
bez--system-site-packages
pip
zostanie zainstalowany./bin
, ale jest to inna wersja (zensurepip
)Oczywiste obejście problemu
pyvenv
z--system-site-packages
:--system-site-packages
opcjiinclude-system-site-packages = false
natrue
wpyvenv.cfg
plikuźródło
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.
źródło
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.
źródło
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.
O cholera, zapomniałem wejść na cd
projects
przed utworzeniem virtualenv i sklonowaniem rep. No cóż, jestem zbyt leniwy, by niszczyć i odtwarzać. Po prostu przeniosę katalog bez żadnych problemów.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ę.
źródło
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_profile
co powinno być już skonfigurowane, aby wrócić do pierwotnego stanu pyenv / pyenv-virtualenv.źródło
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
źródło
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 rootowiByłem bardzo wkurzony! Ale zadziałało!
źródł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.
źródło
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!
źródło
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.
źródło
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
Ponadto, jeśli instalujesz przy użyciu conda, możesz zainstalować bez aktywacji:
źródło
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 -V
pokazuje ścieżkę virtualenv do pipźródło
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 :
Poniżej wyjaśnię szczegółowo ten proces w
Ubuntu
środowisku, to samo dotyczyWindows
iMacOS
.Sens tego zdania jest to, że musimy sprawdzić, czy pierwszy wiersz
#!/path/python
zbin/pip
pliku w środowisku wirtualnym jest poprawna.Jak pierwotnie pokazano w moim pliku:
#!/home/banni/dai/.venv/bin/python3
Uruchom
pip
w 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żpython3
istnieje w folderze, w.venv/bin
którym znajduje się środowisko wirtualne.Sprawdzam bezwzględną ścieżkę do folderu
.venv/bin
. Po wykonaniupwd
polecenia wyświetla:/home/banni/Research/dai/.venv/bin
Uważnie obserwuj, czy
.venv
zmieniła się ścieżka do folderu. Zmień pierwszą linię/bin/pip
pliku na#!/home/banni/Research/dai/.venv/bin/python3
W ten sam sposób sprawdź i zmodyfikuj
bin/activate
plik.Zmieniłem
VIRTUAL_ENV="/home/banni/dai/.venv"
sięVIRTUAL_ENV="/home/banni/Research/dai/.venv"
W tym momencie, po aktywowaniu środowiska wirtualnego,
pip
polecenie 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.
źródło