virtualenv --no-site-packages i pip nadal znajdują pakiety globalne?

136

Miałem wrażenie, virtualenv --no-site-packagesże stworzy całkowicie oddzielne i izolowane środowisko Pythona, ale tak się nie dzieje.

Na przykład mam python-django zainstalowany globalnie, ale chcę stworzyć virtualenv z inną wersją Django.

$ virtualenv --no-site-packages foo       
New python executable in foo/bin/python
Installing setuptools............done.
$ pip -E foo install Django
Requirement already satisfied: Django in /usr/share/pyshared
Installing collected packages: Django
Successfully installed Django

Z tego co wiem, pip -E foo installpowyższe powinno przeinstalować nową wersję Django. Ponadto, jeśli powiem pipowi, aby zamroził środowisko, otrzymam całą masę pakietów. Spodziewałbym się, że dla świeżego środowiska z --no-site-packagestym byłoby puste?

$ pip -E foo freeze
4Suite-XML==1.0.2
BeautifulSoup==3.1.0.1
Brlapi==0.5.3
BzrTools==1.17.0
Django==1.1
... and so on ...

Czy nie rozumiem, jak --no-site-packagespowinno działać?

Ianw
źródło
4
FYI, --no-site-packages stało się przestarzałe. Zobacz tutaj
Salem Ben Mabrouk
@SalemBenMabrouk Link uszkodzony, nowy link tutaj. Powiązany problem na Github: Czy flaga „--no-site-packages” ostatnio zniknęła?
Ynjxsjmh
W tym linku jest napisane --no-site-packagesDEPRECATED. Zachowane tylko w celu zapewnienia zgodności z poprzednimi wersjami. Brak dostępu do globalnych pakietów witryn jest teraz domyślnym zachowaniem . Jeśli chcesz uzyskać dostęp do globalnych pakietów witryn, możesz włączyć --system-site-packages.
Ynjxsjmh

Odpowiedzi:

107

Miałem taki problem, dopóki nie zdałem sobie sprawy, że (na długo przed odkryciem virtualenv) zacząłem dodawać katalogi do PYTHONPATH w moim pliku .bashrc. Ponieważ minęło ponad rok wcześniej, nie pomyślałem o tym od razu.

wobbily_col
źródło
12
Mój bohater! Jeśli chcesz tylko szybko sprawdzić, czy to jest twój problem, możesz uruchomić printenv, aby sprawdzić, czy jest tam PYTHONPATH, a jeśli tak, uruchom nieustawioną PYTHONPATH. Nadal będziesz musiał wyśledzić problem, jeśli nie chcesz, aby problem już się pojawiał, ale pozwoli ci to skonfigurować nowy virtualenv w bieżącej sesji powłoki.
UltraBob
Homebrew też to robi!
Rob
1
Chciałbym móc cię bardziej głosować. Byłem na tej stronie więcej niż raz po tym, jak napotkałem rzeczy, które były spowodowane tym, że moja PYTHONPATH jest już ustawiona.
Bemmu,
Wiem, że to naprawdę (naprawdę) stary post, ale szukałem wszędzie, w tym zadając kilka własnych pytań na temat SO, i nie mogę dowiedzieć się, jak zabrać się --no-site-packagesdo pracy. Zbliżam się do wyczyszczenia Ubuntu i sprawdzenia, czy to naprawi sytuację. Początkowo myślałem, że mam ten sam problem z PYTHONPATH, ale po uruchomieniu printenvgo nie widzę. Frustracja narasta, a każda pomoc jest mile widziana. Moja ścieżka sys.path z wnętrza Venv utworzonego za pomocą --no-site-packageswydaje się zawierać wszystkie moje katalogi z pakietami. Nie mam pojęcia, jak to zmienić. Wsparcie?
NotAnAmbiTurner
Może to również dotyczyć PATHzmiennej globalnej , jeśli szukasz plików wykonywalnych spoza virtualenv.
enderland
27

Musisz upewnić się, że uruchamiasz pipplik binarny w utworzonym środowisku wirtualnym, a nie globalnym.

env/bin/pip freeze

Zobacz test:

Tworzymy virtualenv z --no-site-packagesopcją:

$ virtualenv --no-site-packages -p /usr/local/bin/python mytest
Running virtualenv with interpreter /usr/local/bin/python
New python executable in mytest/bin/python
Installing setuptools, pip, wheel...done.

Sprawdzamy wynik freezez nowo utworzonych pip:

$ mytest/bin/pip freeze
argparse==1.3.0
wheel==0.24.0

Ale jeśli używamy globalnego pip, otrzymujemy to:

$ pip freeze
...
pyxdg==0.25
...
range==1.0.0
...
virtualenv==13.1.2

To znaczy wszystkie pakiety, które pipzostały zainstalowane w całym systemie. Sprawdzając which pip, otrzymujemy (przynajmniej w moim przypadku) coś takiego /usr/local/bin/pip, co oznacza, że ​​kiedy to robimy pip freeze, wywołujemy ten plik binarny zamiast mytest/bin/pip.

fedorqui 'SO przestań szkodzić'
źródło
Miałem ten sam problem. Zastanawiam się, jak to się stało, skoro na początku wywołanie pip freeze pokazało mi poprawne pakiety, ale kilka dni później zaczęło dzwonić do tego znajdującego się w / usr / local / bin / ...
jimijazz
1
To był dla mnie problem: utworzyłem alias pipdo określonej ścieżki do globalnego pip, która nie była nadpisywana podczas aktywacji virtualenv.
merlinND
1
Właśnie mnie uratowałeś, to działało dobrze dla mnie (pip3 i python3.7) Dzięki
Saed Yousef
24

W końcu stwierdziłem, że z jakiegoś powodu pip -E nie działa. Jeśli jednak faktycznie aktywuję virtualenv i używam easy_install dostarczanego przez virtualenv do instalacji pip, to używam pip bezpośrednio z wewnątrz, wydaje się, że działa zgodnie z oczekiwaniami i pokazuje pakiety tylko w virtualenv

Ianw
źródło
2
FWIW, z obecnymi wersjami pip i virtualenv dla trunk, twój pierwotny przepływ pracy teraz robi to dobrze, w każdym razie dla mnie. To powiedziawszy, osobiście nadal unikam -E i po prostu instaluję pip w każdym virtualenv.
Carl Meyer
17

Wiem, że to bardzo stare pytanie, ale dla przyjeżdżających tutaj szukających rozwiązania:

Nie zapomnij aktywować virtualenv ( source bin/activate) przed uruchomieniem pip freeze. W przeciwnym razie otrzymasz listę wszystkich pakietów globalnych.

finspin
źródło
Dziękuję bardzo za to, wiedziałem, że muszę używać source z virtualenv, ale nie z virtualenvwrapper i nigdy nie słyszałem o pip freeze.
Jeszcze
POPRAWNA ODPOWIEDŹ. po zainicjowaniu virtualenv musisz go aktywować lub będziesz korzystać z systemowej wersji Pythona
AsAP_Sherb
16

Tymczasowo wyczyść za PYTHONPATHpomocą:

export PYTHONPATH=

Następnie utwórz i aktywuj środowisko wirtualne:

virtualenv foo
. foo/bin/activate

Tylko wtedy:

pip freeze
Pedro Torres
źródło
15

--no-site-packagespowinien, jak sugeruje nazwa, usunąć standardowy katalog site-packages z sys.path. Wszystko inne, co żyje w standardowej ścieżce Pythona, pozostanie tam.

Martin przeciwko Löwis
źródło
1
Dla mnie mój czyszczenia PYTHONPATHz export PYTHONPATH=wydawało się rade.
jałowiec
4

Podobny problem może wystąpić w systemie Windows, jeśli wywołujesz skrypty bezpośrednio, script.pyktóre następnie używają domyślnego otwieracza systemu Windows i otwierają Pythona poza środowiskiem wirtualnym. Wywołanie go za pomocą python script.pyspowoduje użycie Pythona w środowisku wirtualnym.

odie5533
źródło
Na górze skryptu powinna znajdować się linia z szarpnięciem (zaczynająca się od „! #”), Która będzie wskazywać na interpretowany tekst, który ma zostać użyty.
wobbily_col,
2

Wydaje się, że dzieje się tak również, gdy przenosisz katalog virtualenv do innego katalogu (w systemie Linux) lub zmieniasz nazwę katalogu nadrzędnego.

por
źródło
1

Miałem ten sam problem. Problem dla mnie (na Ubuntu) polegał na tym, że nazwa mojej ścieżki zawierała $. Kiedy stworzyłem virtualenv poza katalogiem $ dir, działało dobrze.

Dziwne.

NotAnAmbiTurner
źródło
1

Jednym z możliwych powodów, dla których virtualenv pip nie działa, jest to, że którykolwiek z folderów nadrzędnych miał miejsce w nazwie, /Documents/project name/app zmieniając jego nazwę , aby /Documents/projectName/approzwiązać problem.

mabdrabo
źródło
1

Napotkałem ten sam problem, w którym pip w venv nadal działa jako globalny pip.
Po przeszukaniu wielu stron rozumiem to w ten sposób.
1. Utwórz nowy venv przez virtualenv z opcją „--no-site-packages”

virtualenv --no-site-packages --python=/xx/xx/bin/python my_env_nmae

proszę zauważyć, że chociaż opcja „--no-site-packages” była domyślnie włączona od 1.7.0 w pliku doc ​​programu virtualenv, ale okazało się, że nie działa, chyba że ustawisz ją ręcznie. Aby uzyskać czyste środowisko, zdecydowanie sugeruję włączenie tej opcji. 2. Aktywuj nowe środowisko, które utworzyłeś

source ./my_env_name/bin/activate
  1. Sprawdź lokalizację pip i lokalizację Pythona i upewnij się, że te dwa polecenia znajdują się w środowisku wirtualnym
pip --version
which python
  1. Użyj pip w wirtualnym środowisku env, aby zainstalować pakiety wolne od globalnej interupcji pakietów
pip install package_name

Chciałbym, żeby ta odpowiedź ci pomogła!

augustus
źródło
0

Oto lista wszystkich opcji instalacji pip - nie znalazłem żadnej -Eopcji ' ', być może miała ją starsza wersja. Poniżej dzielę się prostym angielskim użytkowaniem i pracą virtualenvdla nadchodzących użytkowników SO.


Wszystko wydaje się w porządku, zaakceptuj aktywację virtualenv( foo). Wszystko, co robi, to pozwala nam mieć wiele (i różne) środowisko Pythona, tj. Różne wersje Pythona, różne wersje Django lub dowolny inny pakiet Pythona - na wypadek, gdybyśmy mieli poprzednią wersję w produkcji i chcielibyśmy przetestować najnowsze wydanie Django z naszym podanie.

W skrócie tworzenie i używanie (aktywowanie) środowiska wirtualnego ( virtualenv) umożliwia uruchamianie lub testowanie naszej aplikacji lub prostych skryptów Pythona z różnymi interpreterami Pythona tj. Python 2.7 i 3.3 - może to być nowa instalacja (za pomocą --no-site-packagesopcji) lub wszystkie pakiety z istniejących / ostatnia konfiguracja (za pomocą --system-site-packagesopcji). Aby z niego skorzystać, musimy go aktywować:

$ pip install djangozainstaluje go w globalnych pakietach lokacji i podobnie pobierając pip freezezwróci nazwy globalnych pakietów witryn.

podczas gdy w katalogu venv dir (foo) wykonanie $ source /bin/activateaktywuje venv, tzn. teraz wszystko, co zostało zainstalowane z pip, zostanie zainstalowane tylko w wirtualnym env, a dopiero teraz pip freeze nie pokaże listy globalnych pakietów pythona. Po aktywacji:

$ virtualenv --no-site-packages foo       
New python executable in foo/bin/python
Installing setuptools............done.
$ cd foo
$ source bin/activate 
(foo)$ pip install django

(foo)przed $znakiem wskazuje, że używamy wirtualnego środowiska Pythona, tj. wszystko z pip - install, freeze, uninstall będzie ograniczone do tego venv i nie będzie miało wpływu na globalną / domyślną instalację / pakiety Pythona.

Nabeel Ahmed
źródło