Pip в глобальных пакетах сайтов вместо virtualenv
Использование pip3
для установки пакета в virtualenv
приводит к тому, что пакет устанавливается в папку ackages глобального сайта -p, а не в папку virtualenv. Вот как я настроил Python3 и virtualenv на OS X Mavericks (10.9.1):
Я установил Python3, используя Homebrew:
ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)"
brew install python3 --with-brewed-openssl
Изменена переменная $PATH
в .bash_profile
; добавили следующую строку:
export PATH=/usr/local/bin:$PATH
Запуск which python3
возвращает /usr/local/bin/python3
(после перезапуска оболочки).
Примечание: which python3
все еще возвращает /usr/bin/python
.
Установлено virtualenv
с использованием pip3
:
pip3 install virtualenv
Затем создайте новый virtualenv
и активируйте его:
virtualenv testpy3 -p python3
cd testpy3
source bin/activate
Примечание. Если я не укажу -p python3, pip будет отсутствовать в папке bin в virtualenv.
Работающие which pip
и which pip3
оба возвращают папку virtualenv:
/Users/kristof/VirtualEnvs/testpy3/bin/pip3
Теперь, когда я пытаюсь установить, например, Уценка с помощью pip в активированном virtualenv, pip будет установлена в глобальной папке сайта -p ackages вместо папки сайта -p ackages в virtualenv.
pip install markdown
Запуск pip list
возвращает:
Markdown (2.3.1)
pip (1.4.1)
setuptools (2.0.1)
virtualenv (1.11)
Содержание /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/
Содержание /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/
Как видите, папка глобального сайта -p ackages содержит Markdown, а папка virtualenv - нет.
Примечание: у меня были Python2 и Python3, установленные ранее на другой виртуальной машине (следовал этим инструкциям), и у меня была та же проблема с Python3; установка пакетов в Python2 на основе virtualenv работала безупречно.
Любые советы, подсказки,... будет очень признателен.
Ответы
Ответ 1
Забавно, что ты это сделал, у меня была точно такая же проблема. Я решил это в конечном счете, но я все еще не уверен, что это вызвало.
Попробуйте проверить сценарии bin/pip
и bin/activate
. В bin/pip
посмотрите на shebang. Правильно ли это? Если нет, исправьте это. Затем на линии ~ 42
в bin/activate
проверьте, правильно ли ваш виртуальный путь. Это будет выглядеть примерно так.
VIRTUAL_ENV="/Users/me/path/to/virtual/environment"
Если это неправильно, исправьте его, deactivate
, затем . bin/activate
, и если наша общая проблема имеет ту же причину, она должна работать. В любом случае, если вы этого не сделаете, вы на правильном пути. Я прошел ту же процедуру решения проблем, что и вы, which pip
снова и снова, после трассировки стека и т.д.
Убедитесь, что
/Users/kristof/VirtualEnvs/testpy3/bin/pip3
- это то, что вы хотите, и не ссылаетесь на другой аналогично названный тестовый проект (у меня была эта проблема, и я понятия не имею, как это началось. Мое подозрение запускает несколько виртуальных виртуальных машин одновременно).
Если это не работает, может быть временное решение, как сказал Джо Холлоуэй,
Просто запустите виртуальный диск с полным путем (т.е. не полагайтесь на поиск исполняемого пути), и вам даже не нужно активировать среду. Это будет сделано правильно.
Возможно, не идеальный, но он должен работать в крайнем случае.
Ссылка на мой оригинальный вопрос:
VirtualEnv/Pip пытается установить пакеты по всему миру
Ответ 2
Для меня это не проблема с пипсом или virtualenv. Это была проблема с python. Я установил свой $PYTHONPATH вручную в ~/.bash_profile (или ~/.bashrc) после того, как после некоторого обучающего онлайн. Это вручную задано значение $PYTHONPATH было доступно в virtualenv, так как это, вероятно, должно быть разрешено.
Дополнительно add2virtualenv
не добавлял мой путь к моему $PYTHONPATH по какой-то причине в virtualenv.
Просто несколько путей разветвления для тех, кто все еще может застрять! Ура!
Ответ 3
У меня была та же проблема, я решил ее, удалив каталог venv и воссоздав его!
deactivate (if venv is activated first deactivate it)
rm -rf venv
virtualenv -p python3 venv
. ENV/bin/activate
pip3 install -r requirements.txt
Теперь все работает как шарм.
Ответ 4
У меня тоже была эта проблема. Вызов pip install <package_name>
из каталога /bin
в моей виртуальной среде Python 3.3 на моем Mavericks Mac заставил пакет Python быть установленным в каталоге пакетов пакетов Python 2.7. Это было несмотря на то, что моя $PATH началась с каталога, содержащего pip
. Weird. Это не происходит в CentOS. Для меня решение вызывало pip3
вместо pip
. Когда я установил пик в виртуальную среду через ez_setup, в каталоге /bin
были установлены три исполняемых файла "pip" - pip
, pip3
и pip3.3
. Любопытно, что все три файла были точно такими же. Вызов pip3 install <package_name>
привел к тому, что пакет Python был правильно установлен в каталог локальных сайтов. Вызов pip
с полным именем пути в виртуальную среду также работал правильно. Мне было бы интересно узнать, почему мой Mac не использует $PATH так, как я ожидал.
Ответ 5
Я попал в ту же проблему при установке пакета python из virtualenv.
Основная причина в моем случае была иной.
Изнутри virtualenv я (по привычке на Ubuntu), делал:
sudo easy_install -Z <package>
Это заставило игнорировать bin/pip shebang и использовать корневой виртуальный скрипт для установки в глобальных пакетах сайтов.
Поскольку у нас есть виртуальная среда, мы должны установить пакет без "sudo"
Ответ 6
Первое, что нужно проверить, - это то, куда адресуется решение:
which pip
Если вы находитесь в виртуальной среде, вы ожидаете, что это даст вам что-то вроде:
/path/to/virtualenv/.name_of_virtualenv/bin/pip
Однако может случиться так, что он по какой-то причине разрешает вашу систему. Например, вы можете увидеть это из своего виртуального (это плохо):
/USR/локальные/бен/пип (или что-либо, что не находится в вашем виртуальном пути).
Чтобы решить эту проблему, выполните команду pipconfig:
~/.pipconf
~/.conf/pip
/etc/pip.conf
и убедитесь, что нет ничего, что принуждает ваш путь к Python или путь к нему (это исправлено для меня).
Затем попробуйте запустить новый терминал и перестроить свой virtualenv (удалить, затем создать его снова)
Ответ 7
У меня была аналогичная проблема после обновления до pip==8.0.0
. Пришлось прибегнуть к отладке пипса, чтобы проследить неудачный путь.
Как оказалось, у моего каталога профиля был файл конфигурации distutils с пустым значением пути. Это привело к тому, что все пакеты были установлены в один и тот же корневой каталог вместо соответствующей виртуальной среды (в моем случае /lib/site-packages
).
Я не знаю, как появился файл конфигурации или как у него были пустые значения, но он начался после обновления pip.
Если кто-то еще сталкивается с этой же проблемой, просто удаление файла ~/.pydistutils.cfg
(или удаление пустого пути конфигурации) устраняет проблему в моей среде, потому что pip вернулся к распределенной конфигурации по умолчанию.
Ответ 8
Я наткнулся на ту же проблему с Манджаро. Я создал виртуальную среду, используя python3 -m ven venv
, а затем активировал, используя source venv/bin/actiave
. which python
и which pip
оба указывали на правильные двоичные файлы в virtualenv, однако я не смог установить на virtualenv даже при использовании полного пути двоичных файлов. Оказалось, что когда я удалил пакет python-pip с sudo pacman -R python-pip python-reportlab
(должен был включать reportlab для удовлетворения зависимостей), все начало работать как положено. Не знаю почему, но это, вероятно, связано с двойной установкой, когда системный пакет имеет преимущество.
Ответ 9
Произошла одна и та же проблема. Я просто переустановил pip глобально с помощью sudo easy_install pip
(OSX/Max), а затем снова создал свой virtualenv с помощью sudo virtualenv nameOfVEnv
. Затем после активации нового virtualenv команда pip
работала, как ожидалось.
Я не думаю, что использовал sudo
при первом создании virtualenv, и, возможно, это было причиной отсутствия доступа к pip
изнутри virtualenv, я смог получить доступ к pip2
до этого исправить, хотя это было странно.
Ответ 10
Вот некоторые методы, которые могли бы избежать головных болей при использовании Виртуальных сред:
- Создайте папку для ваших проектов.
- Создайте проекты Virtualenv внутри этой папки.
- После активации среды вашего проекта никогда не используйте пакет sudo pip install.
- После завершения вашей работы всегда " деактивировать" вашу среду.
- Избегайте переименования папки проекта.
Для лучшего представления этих практик, вот симуляция:
создание папки для ваших проектов/сред
$ mkdir venv
создание среды
$ cd venv/
$ virtualenv google_drive
New python executable in google_drive/bin/python
Installing setuptools, pip...done.
активирующая среда
$ source google_drive/bin/activate
установка пакетов
(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...
пакет, доступный внутри среды
(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()
>>>
отключить среду
(google_drive) $ deactivate
$
пакет НЕ ДОСТУПНО вне среды
(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
>>>
Примечания:
Почему бы не sudo?
Virtualenv создает для вас совершенно новую среду, определяя $PATH и некоторые другие переменные и настройки. Когда вы используете пакет sudo pip install, вы запускаете Virtualenv как root, избегая создания всей созданной среды и затем устанавливая пакет на глобальных сайтах-пакетах, и не внутри папки проекта, где у вас есть виртуальная среда, хотя вы активировали среду.
Если вы переименуете папку своего проекта (как указано в принятом ответе)...
... вам придется настроить некоторые переменные из некоторых файлов в каталоге bin вашего проекта.
Например:
bin/pip, строка 1 (She Bang)
bin/activate, строка 42 (VIRTUAL_ENV)
Ответ 11
У меня была эта проблема. Оказалось, что в одном из имен моей папки было место, которое вызвало проблему. Я удалил пространство, удалил и восстановил с помощью venv, и все было хорошо.
Ответ 12
Эта проблема возникает при создании экземпляра virtualenv и изменении имени родительской папки.
Ответ 13
Ни одно из вышеперечисленных решений не помогло мне.
Мой венв был активным. pip -V
и which pip
дал мне правильный путь virtualenv, но когда я pip install
pip-пакеты -ed с активированным venv, моя остановка pip freeze
осталась пустой.
Все переменные среды тоже были правильными.
Наконец, я просто изменил pip и удалил virtualenv:
easy_install pip==7.0.2
pip install pip==10
sudo pip uninstall virtualenv
Переустановите venv:
sudo pip install virtualenv
Создать венв:
python -m virtualenv venv_name_here
И все пакеты снова правильно установлены в моем venv.
Ответ 14
Перейдите в каталог bin в вашей виртуальной среде и напишите так:
./pip3 install <package-name>
Ответ 15
После создания виртуальной среды попробуйте использовать pip, расположенный в yourVirtualEnvName\Scripts
Следует установить пакет внутри Lib\site-packages в вашей виртуальной среде
Ответ 16
У меня тоже была эта проблема. Вызов sudo pip install
привел к тому, что пакеты Python были установлены в глобальном каталоге пакетов, а вызов pip install
работал нормально.
Поэтому не используйте sudo в virtualenv.
Ответ 17
Та же проблема. Python3.5 и pip 8.0.2 установлены из Linux rpm
.
Я не нашел основной причины и не могу дать правильный ответ. Похоже, существует несколько возможных причин.
Однако я надеюсь, что смогу помочь поделиться своим наблюдением и обходным путем.
Очевидное обходное решение для pyvenv
с --system-site-packages
:
- создайте его без опции
--system-site-packages
- измените
include-system-site-packages = false
на true
в pyvenv.cfg
файле
Ответ 18
Также стоит проверить, что вы каким-то образом не изменили путь к вашему virtualenv.
В этом случае первая строка в bin/pip
(и остальная часть исполняемых файлов) будет иметь неправильный путь.
Вы можете либо отредактировать эти файлы, либо исправить путь, либо удалить и снова установить virtualenv.
Ответ 19
Для Python 3ers
Попробуйте обновить. У меня была такая же проблема, и я попробовал ответ Чейз, но безуспешно. Самый быстрый способ реорганизовать это - обновить версию Python Minor/Patch, если это возможно. Я заметил, что я запускал 3.5.1 и обновлялся до 3.5.2. Певнов снова работает.
Ответ 20
Это случилось со мной, когда я создал virtualenv в неправильном месте. Затем я подумал, что могу переместить каталог в другое место без какого-либо значения. Это имело значение.
mkdir ~/projects
virtualenv myenv
cd myenv
git clone [my repository]
О, дерьмо, я забыл перейти в projects
прежде чем создавать virtualenv и клонировать представителя. Да ладно, мне лень разрушать и воссоздавать. Я просто перенесу каталог без проблем.
cd ~
mv myenv projects
cd projects/myenv/myrepo
pip install -r requirements
Нет, хочет больше разрешений, что? Я думал, что это было странно, но SUDO AWAY! Затем он установил пакеты в глобальное местоположение.
Урок, который я усвоил, был, просто удалите virtualenv dir. Не двигай это.
Ответ 21
Возникла эта проблема после установки Divio: он каким-то образом изменил мой PATH или окружение, так как запускает терминал.
Решением в этом случае было просто сделать source ~/.bash_profile
который уже должен быть настроен, чтобы вернуть вас в исходное состояние pyenv/pyenv-virtualenv.
Ответ 22
Каким-то образом файл setup.cfg с префиксом = "" в папке проекта
запуск pip install на virtualenv вне папки проекта работал так, что изнутри он говорил pip использовать пустой префикс по умолчанию "/"
удаление файла исправило это
Ответ 23
Это случилось со мной, когда я установил virtualenv с --python=python3.6
но потом попытался использовать pip2 install
.
Создание virtualenv с флагом версии, которую вы будете использовать, решает проблемы с разрешениями. Чтобы проверить, попробуйте which pip
which pip2
или which pip3
(зависит от вашего выбора). Если какой - либо pip
вы используете показывает путь не venv
здесь ваша проблема.
Ответ 24
У меня была эта проблема, и после попытки всего вышеупомянутого решения я просто удалил все и начал заново.
В моем собственном случае я использовал sudo
при создании одной из папок, в которой существовала виртуальная среда, и sudo передает привилегии root
Я был очень зол! Но это сработало!
Ответ 25
По какой-то причине я должен использовать 'sudo' для установки пакетов через pip в моей системе Ubuntu. Это приводит к установке пакетов в глобальных пакетах сайта. Положите это здесь для тех, кто может столкнуться с этой проблемой в будущем.
Ответ 26
У меня была именно проблема из названия, и я ее решил. Пип начал устанавливать в пакеты сайта venv после того, как я очистил свой PATH: в самом начале у него был путь к моей локальной директории ~/bin.
Итак, мой совет: тщательно проверяйте переменные среды на предмет "мусора" или каких-либо нестандартных вещей. К сожалению, virtualenv может быть чувствительным к ним.
Удачи!
Ответ 27
Много хорошего обсуждения выше, но были использованы примеры virtualenv. Поскольку "conda" теперь является рекомендуемым инструментом для управления virtualenv, я суммировал шаги по запуску pip в conda env следующим образом.
Я буду использовать py36r в качестве имени env, а /opt/conda/envs - это префикс envs):
$ source/opt/conda/etc/profile.d/conda.sh # пропустить, если уже сделано
$ conda активировать py36r
$ pip install pkg_xyz
$ pip list | grep pkg_xyz
Обратите внимание, что выполняемый пункт должен быть в /opt/conda/envs/py36r/bin/pip (не /opt/conda/bin/pip).
Кроме того, вы можете просто запустить следующее без активации Conda
$/opt/conda/envs/py36r/bin/pip
Также, если вы устанавливаете с помощью conda, вы можете установить без активации:
$ conda install -n py36r pkg_abc...