У меня сложилось впечатление, что virtualenv --no-site-packages
это создаст совершенно отдельную и изолированную среду Python, но, похоже, это не так.
Например, у меня есть python-django, установленный глобально, но я хочу создать virtualenv с другой версией 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
Из того, что я могу сказать, pip -E foo install
вышеизложенное должно переустановить новую версию Django. Также, если я скажу pip заморозить среду, я получу много пакетов. Я ожидаю, что для свежей среды с --no-site-packages
этим будет пустым?
$ 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 ...
Я неправильно понимаю, как --no-site-packages
должен работать?
python
virtualenv
pip
ianw
источник
источник
--no-site-packages
что УСТАРЕЛО. Сохраняется только для обратной совместимости. Отсутствие доступа к глобальным пакетам сайтов теперь является поведением по умолчанию . Если вы хотите получить доступ к глобальным пакетам сайта, вы можете включить--system-site-packages
.Ответы:
У меня была такая проблема, пока я не понял, что (задолго до того, как я обнаружил virtualenv), я добавил каталоги к PYTHONPATH в своем файле .bashrc. Поскольку это было более года назад, я не думал об этом сразу.
источник
--no-site-packages
к работе. Я близок к тому, чтобы просто стереть Ubuntu и посмотреть, исправит ли это что-то. Сначала я думал, что у меня та же проблема с PYTHONPATH, но при бегеprintenv
я ее не вижу. Разочарование растет, и любая помощь очень ценится. Мой sys.path из venv, созданного с помощью,--no-site-packages
кажется, включает в себя все мои каталоги пакетов. Я не знаю, как это изменить. Помогите?PATH
переменной, если вы также находите исполняемые файлы за пределами virtualenv.Вы должны убедиться, что вы запускаете
pip
двоичный файл в виртуальной среде, которую вы создали, а не в глобальной.Смотрите тест:
Мы создаем virtualenv с
--no-site-packages
опцией:Мы проверяем вывод
freeze
вновь созданногоpip
:Но если мы используем глобальный
pip
, это то, что мы получаем:То есть все пакеты, которые
pip
установлены во всей системе. Проверяя,which pip
мы получаем (по крайней мере, в моем случае) что-то вроде того/usr/local/bin/pip
, что означает, что когда мы делаемpip freeze
это, мы вызываем этот двоичный файл вместоmytest/bin/pip
.источник
pip
с определенным путем к глобальному пункту, который не был переопределен при активации virtualenv.В конце концов я обнаружил, что по какой-то причине пип-Э не работает. Тем не менее, если я на самом деле активирую virtualenv и использую easy_install, предоставляемый virtualenv, для установки pip, а затем использую pip непосредственно изнутри, кажется, что он работает должным образом и показывает пакеты только в virtualenv.
источник
Я знаю, что это очень старый вопрос, но для тех, кто прибывает сюда в поисках решения:
Не забудьте активировать virtualenv (
source bin/activate
) перед запускомpip freeze
. В противном случае вы получите список всех глобальных пакетов.источник
Временно очистите с
PYTHONPATH
помощью:Затем создайте и активируйте виртуальную среду:
Только затем:
источник
--no-site-packages
следует, как следует из названия, удалить стандартный каталог site-packages изsys.path
. Все остальное, что живет в стандартном пути Python, останется там.источник
PYTHONPATH
с,export PYTHONPATH=
казалось, добилась цели.Аналогичная проблема может возникнуть в Windows, если вы вызываете сценарии напрямую,
script.py
которые затем используют средство открытия Windows по умолчанию и открывают Python вне виртуальной среды. Вызов с помощьюpython script.py
будет использовать Python с виртуальной средой.источник
Это также происходит, когда вы перемещаете каталог virtualenv в другой каталог (в linux) или переименовываете родительский каталог.
источник
У меня была такая же проблема. Проблема для меня (в Ubuntu) заключалась в том, что мой путь содержал имя
$
. Когда я создал virtualenv за пределами $ dir, он работал нормально.Weird.
источник
Одна из возможных причин, почему virtualenv pip не будет работать, заключается в том, что в какой-либо из родительских папок было место в имени,
/Documents/project name/app
переименовывая его для/Documents/projectName/app
решения проблемы.источник
Я столкнулся с той же проблемой, когда pip in venv по-прежнему работает как глобальный pip.
После поиска многих страниц, я понимаю это таким образом.
1. Создайте новый venv с помощью virtualenv с опцией "--no-site-packages"
обратите внимание, что хотя опция «--no-site-packages» была по умолчанию true, начиная с 1.7.0 в doc-файле virtualenv, но я обнаружил, что она не работает, если вы не включили ее вручную. Чтобы получить чистый венв, я настоятельно рекомендую включить эту опцию 2. Активировать созданный вами новый env
Желаю, чтобы этот ответ помог вам!
источник
Вот список всех опций установки pip - я не нашел ни одной
-E
опции, возможно, она была в более старой версии. Ниже я делюсь простым использованием английского языка и работойvirtualenv
для будущих пользователей SO.Кажется, все хорошо, примите активацию
virtualenv
(foo
). Все, что он делает, - это позволяет нам иметь несколько (и разную) среду Python, то есть различные версии Python, или различные версии Django, или любой другой пакет Python - в случае, если у нас есть предыдущая версия в производстве и мы хотим протестировать последнюю версию Django с нашим применение.Короче говоря, создание и использование (активация) виртуальной среды (
virtualenv
) позволяет запускать или тестировать наше приложение или простые сценарии Python с другим интерпретатором Python, т.е. Python 2.7 и 3.3 - может быть новой установкой (с использованием--no-site-packages
опции) или всеми пакетами из существующих / последняя настройка (используя--system-site-packages
опцию). Чтобы использовать это, мы должны активировать это:$ pip install django
установит его в глобальные пакеты сайтов и аналогичным образомpip freeze
получит имена глобальных пакетов сайтов.в то время как внутри venv dir (foo) при выполнении
$ source /bin/activate
активирует venv, т.е. теперь все, что установлено с помощью pip, будет установлено только в виртуальном env, и только теперь замораживание pip не выдаст список глобальных пакетов python для пакетов сайта. После активации:(foo)
до того, как$
знак укажет, что мы используем виртуальную среду Python, т.е. любая вещь с pip - install, freeze, uninstall будет ограничена этим venv и не повлияет на глобальные / стандартные установки / пакеты Python.источник
Моя проблема была
pip
иpython3
версии. Для последней версииdjango
установки,pip3
необходимо. Поэтому моя проблема была решена после создания виртуальной среды с помощью следующих команд:источник