virtualenv --no-site-packages и pip все еще находят глобальные пакеты?
У меня сложилось впечатление, что 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 должен работать?
15 ответов
У меня была такая проблема, пока я не понял, что (задолго до того, как я обнаружил virtualenv), я добавил каталоги к PYTHONPATH в своем файле.bashrc. Как и раньше, я не сразу об этом подумал.
Вы должны убедиться, что вы используете pip двоичный файл в виртуальной среде, которую вы создали, а не глобальный.
env/bin/pip freeze
Смотрите тест:
Мы создаем virtualenv с --no-site-packages опция:
$ 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.
Мы проверяем вывод freeze из недавно созданного pip:
$ mytest/bin/pip freeze
argparse==1.3.0
wheel==0.24.0
Но если мы используем глобальный pipвот что мы получаем:
$ pip freeze
...
pyxdg==0.25
...
range==1.0.0
...
virtualenv==13.1.2
То есть все пакеты, которые pip установлен во всей системе. Проверяя which pip мы получаем (по крайней мере, в моем случае) что-то вроде /usr/local/bin/pipЭто означает, что когда мы делаем pip freeze он вызывает этот двоичный файл вместо mytest/bin/pip,
В конце концов я обнаружил, что по какой-то причине пип-Э не работает. Однако, если я на самом деле активирую virtualenv и использую easy_install, предоставляемый virtualenv, для установки pip, а затем использую pip непосредственно изнутри, похоже, он работает должным образом и показывает только пакеты в virtualenv.
Временно очистить PYTHONPATH с:
export PYTHONPATH=
Затем создайте и активируйте виртуальную среду:
virtualenv foo
. foo/bin/activate
Только затем:
pip freeze
Я знаю, что это очень старый вопрос, но для тех, кто прибывает сюда в поисках решения:
Не забудьте активировать virtualenv (source bin/activate) перед запуском pip freeze, В противном случае вы получите список всех глобальных пакетов.
--no-site-packages следует, как следует из названия, удалить стандартный каталог site-packages из sys.path, Все остальное, что живет в стандартном пути Python, останется там.
Подобная проблема может возникнуть в Windows, если вы вызываете сценарии напрямую как script.py который затем использует открыватель Windows по умолчанию и открывает Python за пределами виртуальной среды. Называя это с python script.py будет использовать Python с виртуальной средой.
Это также происходит, когда вы перемещаете каталог virtualenv в другой каталог (в linux) или переименовываете родительский каталог.
Одна из возможных причин, почему virtualenv pip не будет работать, заключается в том, что в какой-либо из родительских папок было место в имени /Documents/project name/appпереименовав его в /Documents/projectName/app решает проблему.
У меня была такая же проблема. Проблема для меня (в Ubuntu) заключалась в том, что мой путь содержал $, Когда я создал virtualenv за пределами $ dir, он работал нормально.
Weird.
Вот список всех опций установки 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 для пакетов сайтов. После активации:
$ 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) перед $ Знак указывает, что мы используем виртуальную среду Python, т.е. любая вещь с pip - install, freeze, uninstall будет ограничена этим venv и не повлияет на глобальные / стандартные установки / пакеты Python.
для тех, кто обновился до Ubuntu 22.04 или смущен той же проблемой, сначала удалите установленный pip, переустановите pip в /usr/local/bin, согласно документу на python.org, к моменту выхода 3.10.5 запустите :
sudo python get-pip.py --prefix=/usr/
вам нужно загрузить скрипт, если у вас его нет. После возврата сообщения об успешном завершении установите virtualenv или поэзию, он заметит, что /usr/local недоступен для записи, и будет установлен в ~/.local/what/ever, это здорово. И тогда все готово, используйте virtualenv для повторного создания папки venv в каталоге вашего проекта. если случилось что-то странное, используйте команду, чтобы проверить путь к pip3 или virtualenv и удалить их.
Моя проблема заключалась в том, что я установил виртуальную среду следующим образом:
python3 -m venv venv
Затем после активации venv я побежал
python3 main.py
Который просто полагался на глобальные пакеты, так как не предлагал мне устанавливать пакеты.
Запуск ниже сделал свое дело
python main.py
Я столкнулся с той же проблемой, когда pip в venv по-прежнему работает как глобальный pip.
После поиска на многих страницах я понял это так.
1. Создайте новый venv с помощью virtualenv с опцией "--no-site-packages"
virtualenv --no-site-packages --python=/xx/xx/bin/python my_env_nmae
обратите внимание, что хотя опция "--no-site-packages" была по умолчанию истинной с версии 1.7.0 в файле документации virtualenv, но я обнаружил, что она не работает, если вы не установите ее вручную. Чтобы получить чистый Venv, я настоятельно рекомендую включить эту опцию 2. Активируйте новый env, который вы создали.
source ./my_env_name/bin/activate
- Проверьте местоположение вашего пункта и местоположение Python и убедитесь, что эти две команды находятся в виртуальной среде.
pip --version
which python
- Используйте pip под виртуальным окружением для установки пакетов без прерывания глобальных пакетов
pip install package_name
Желаю, чтобы этот ответ помог вам!
Моя проблема заключалась в pip а также python3версии. Для последней версииdjango установка, pip3является необходимым. Итак, моя проблема была решена после создания виртуальной среды с помощью следующих команд:
> virtualenv --python=python3 venv
> source venv/bin/activate
> which pip3 #should be different from /usr/local/bin/pip3
...<some-directory>/venv/bin/pip3
PS Эта проблема возникла из-за того, что версия моего python по умолчанию в ubuntu была 2.7. Используя указанную выше команду, он проигнорирует версию по умолчанию.