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

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ć?

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.

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.

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

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.

Tymczasowo wyczyść za PYTHONPATHpomocą:

export PYTHONPATH=

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

virtualenv foo
. foo/bin/activate

Tylko wtedy:

pip freeze

--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.

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.

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

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.

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.

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

3. Sprawdź lokalizację pip i lokalizację Pythona i upewnij się, że te dwa polecenia znajdują się w środowisku wirtualnym

pip --version
which python

4. 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!

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.