Использование pip3
для установки пакета в a virtualenv
приводит к тому, что пакет устанавливается в глобальную папку site-packages, а не в папку 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
Теперь, когда я пытаюсь установить, например, Markdown, используя pip в активированном virtualenv, pip будет устанавливаться в глобальной папке site-packages вместо папки site-packages в 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/
Как видите, папка global site-packages содержит Markdown, а папка virtualenv - нет.
Примечание. У меня ранее были установлены Python2 и Python3 на другой виртуальной машине (следовал этим инструкциям), и у меня была такая же проблема с Python3; Однако установка пакетов в virtualenv на базе Python2 работала безупречно.
Любые советы, подсказки,… были бы очень признательны.
источник
pip3
?). Это может быть неплохо само по себе, но вы должны знать, если это так.Ответы:
Забавно, что ты поднял это, у меня была точно такая же проблема. В конце концов я решил это, но до сих пор не уверен, чем это вызвано.
Попробуйте проверить свои
bin/pip
иbin/activate
сценарии. Вbin/pip
, посмотрите на shebang. Это правильно? Если нет, поправьте. Затем в строке ~42
в вашемbin/activate
проверьте правильность вашего пути virtualenv. Это будет выглядеть примерно такЕсли это не так, исправить ее,
deactivate
, а затем. bin/activate
, и если наша обоюдная проблема была та же самая причина, она должна работать. Если это все еще не так, вы все равно на правильном пути. Я прошел через ту же процедуру решения проблем, что и вы,which pip
снова и снова, отслеживая трассировку стека и т. Д.Убедитесь, что
это то, что вы хотите, и не ссылаетесь на другой тестовый проект с таким же названием (у меня была эта проблема, и я понятия не имею, как она началась. Я подозреваю, что одновременно запущено несколько виртуальных серверов).
Если ничего из этого не сработает, временным решением может быть, как сказал Джо Холлоуэй:
Возможно, не идеально, но он должен работать в крайнем случае.
Ссылка на мой исходный вопрос:
VirtualEnv / Pip пытается установить пакеты глобально
источник
#!/usr/local/bin/python3.3
вместо#!/Users/kristof/VirtualEnvs/testpy3/bin/python3.3
. Я изменил его, активировал virtualenv и установил пакет Markdown. Pip теперь устанавливается в папку пакетов сайта virtualenv вместо глобальной.activate
сценарий был хорошо, но будьте осторожны , все этиpip*
сценарии иeasy_install*
сценарии имеют неправильную хижину. Все они должны быть исправлены вручную. Я не смог исправить их, переустановив pip или что-то в этом роде. Кроме того, пояснение к обходному пути Джо Холлоуэя: проблема не в том, что оболочка ищет pip, а в том, что pip явно указывает неправильный питон. Поэтому вам нужно будет указать питон самостоятельно, например:$ ~/.virtualenvs/venv/bin/python ~/.virtualenvs/venv/bin/pip --version
--relocatable
моего env, и строка 42 неверна. Похоже, что--relocatable
это не помогло.Для меня это не было проблемой pip или virtualenv. Это была проблема с питоном. Я установил свой $ PYTHONPATH вручную в ~ / .bash_profile (или ~ / .bashrc) после прохождения некоторого онлайн-руководства. Этот вручную установленный $ PYTHONPATH был доступен в virtualenv, поскольку это, вероятно, должно быть разрешено.
Кроме того,
add2virtualenv
по какой-то причине в virtualenv не добавлялся мой путь к проекту в мой $ PYTHONPATH.Просто несколько разветвляющихся путей для тех, кто все еще может застрять! Ура!
источник
У меня была такая же проблема, я решил ее, удалив каталог venv и воссоздав его!
Теперь все работает как шарм.
источник
pip3
то время как virtualenv по умолчанию использовал python2, используяpip
вместоpip3
. Я проверил, неbin
нашелpip3
. Использованиеvirtualenv -p python3 venv
решило проблему.У меня тоже была эта пробема. Вызов
pip install <package_name>
из/bin
каталога в моей виртуальной среде Python 3.3 на моем Mac Mavericks привел к установке пакета Python в каталог пакетов глобального сайта Python 2.7. И это несмотря на то, что моя $ PATH началась с каталога, содержащего файлыpip
. Странно. На CentOS этого не происходит. Для меня решение было вызовомpip3
вместоpip
. Когда я установил пипс в виртуальной среде через ez_setup , три «пип» исполняемые файлы были установлены в/bin
каталоге -pip
,pip3
иpip3.3
. Любопытно, что все три файла были абсолютно одинаковыми. Вызовpip3 install <package_name>
вызвал правильную установку пакета Python в локальный каталог пакетов сайта. Вызовpip
с полным путем в виртуальную среду также работал правильно. Мне было бы интересно узнать, почему мой Mac не использует $ PATH так, как я ожидал.источник
Первое, что нужно проверить, это то, к какому местоположению разрешается точка:
если вы находитесь в virtualenv, вы ожидаете, что это даст вам что-то вроде:
Однако может случиться так, что по какой-то причине он разрешается в вашей системе. Например, вы можете увидеть это изнутри своего virtualenv (это плохо):
Чтобы решить эту проблему, проверьте свой pipconfig в:
и убедитесь, что ничто не заставляет ваш путь Python или ваш путь к пипу (это исправило это для меня).
Затем попробуйте запустить новый терминал и перестроить виртуальный сервер (удалите, а затем создайте его снова)
источник
/etc/pip.conf
! У меня была аналогичная проблема, и после долгой отладки я понял, что кто-то неправильно сконфигурировал систему, над которой я работал, возился с этим файлом.which pip
все еще давал мне правильный путь!Я столкнулся с той же проблемой при установке пакета python из virtualenv. Основная причина в моем случае была другой. Внутри virtualenv я (по привычке в Ubuntu) делал:
Это привело к тому, что bin / pip shebang игнорировался, и он использовал root non virtualenv python для его установки в глобальные пакеты сайтов. Поскольку у нас есть виртуальная среда, мы должны установить пакет без "sudo"
источник
Я столкнулся с той же проблемой при запуске Manjaro. Я создал виртуальную среду с помощью,
python3 -m ven venv
а затем активировал с помощьюsource venv/bin/actiave
.which python
иwhich pip
оба указали на правильные двоичные файлы в virtualenv, однако мне не удалось установить на virtualenv, даже при использовании полного пути к двоичным файлам. Оказалось, что когда я удалил пакет python-pip сsudo pacman -R python-pip python-reportlab
(пришлось включить reportlab для удовлетворения зависимостей), все начало работать, как ожидалось. Не уверен, почему, но это, вероятно, связано с двойной установкой, когда системный пакет имеет приоритет.источник
python-pip
через pamac, и pip virtualenv продолжал работать правильно. Не совсем уверен, что происходит, но я согласен с вашей оценкой проблемы двойной установки.У меня была аналогичная проблема после обновления до
pip==8.0.0
. Пришлось прибегнуть к отладочной программе, чтобы отследить плохой путь.Как оказалось, в моем каталоге профиля был файл конфигурации distutils с некоторыми пустыми значениями пути. Это приводило к установке всех пакетов в один и тот же корневой каталог вместо соответствующей виртуальной среды (в моем случае
/lib/site-packages
).Я не уверен, как туда попал файл конфигурации или как у него были пустые значения, но он запустился после обновления pip.
Если кто-то еще наткнется на эту же проблему, простое удаление файла
~/.pydistutils.cfg
(или удаление пустого пути конфигурации) устранило проблему в моей среде, потому что pip вернулся к распределенной конфигурации по умолчанию.источник
[install]\nprefix=
Перейдите в каталог bin в вашей виртуальной среде и напишите так:
источник
У меня была такая же проблема на macos с установленным python 2 и 3.
Кроме того, у меня были псевдонимы, указывающие на python3 и pip3 в моем
.bash_profile
.Устранена
python3 -m venv venv
проблема с удалением псевдонимов и воссозданием виртуального окружения .источник
Сегодня столкнулся с той же проблемой. Я просто переустановил pip глобально с помощью
sudo easy_install pip
(OSX / Max), а затем снова создал свой virtualenv с помощьюsudo virtualenv nameOfVEnv
. Затем после активации нового virtualenvpip
команда работала, как ожидалось.Не думаю, что я использовал
sudo
первое создание virtualenv, и это могло быть причиной того, что у меня не было доступаpip
из virtualenv, кpip2
которому я мог получить доступ до этого исправления, хотя это было странно.источник
virtualenv
было запустить сноваВот несколько приемов, которые помогут избежать головной боли при использовании виртуальных сред:
Чтобы лучше представить эту практику, вот симуляция:
создание папки для ваших проектов / сред
создавая среду
активирующая среда
установка пакетов
пакет доступен внутри среды
деактивировать среду
пакет НЕ ДОСТУПЕН за пределами среды
Ноты:
Почему не sudo?
Если вы переименуете папку своего проекта (как указано в принятом ответе) ...
источник
У меня была такая проблема. Оказалось, что в одном из имен моих папок был пробел, который вызвал проблему. Я удалил пространство, удалил и восстановил с помощью venv, и все было хорошо.
источник
Эта проблема возникает при создании экземпляра virtualenv и последующем изменении имени родительской папки.
источник
Ни одно из вышеперечисленных решений не помогло мне.
Мой венв был активен.
pip -V
иwhich pip
дал мне правильный путь virtualenv, но когда яpip install
-ed пакеты с активированным venv, моиpip freeze
остались пустыми.Все переменные среды тоже были правильными.
Наконец, я просто изменил pip и удалил virtualenv:
Переустановите venv:
Создайте venv:
И все пакеты снова были правильно установлены в мой venv.
источник
После создания виртуальной среды попробуйте использовать pip, расположенный в yourVirtualEnvName \ Scripts
Он должен установить пакет внутри Lib \ site-packages в вашей виртуальной среде.
источник
У меня тоже была эта пробема. Вызов
sudo pip install
вызвал установку пакетов Python в глобальный каталог пакетов сайтов, и вызовpip install
работал нормально. Так что не используйте sudo в virtualenv.источник
sudo su
за которым<venv>/bin/activate
следуетpip install
.Та же проблема. Python3.5 и pip 8.0.2 устанавливаются из Linux
rpm
.Я не нашел первопричины и не могу дать правильный ответ. Похоже, есть несколько возможных причин.
Однако я надеюсь, что смогу поделиться своими наблюдениями и обходным путем.
pyvenv
с участием--system-site-packages
./bin
не содержитpip
,pip
доступно из пакетов сайта системыpyvenv
без--system-site-packages
pip
устанавливается./bin
, но это другая версия (изensurepip
)Очевидный способ решения
pyvenv
с--system-site-packages
:--system-site-packages
опцииinclude-system-site-packages = false
чтобыtrue
вpyvenv.cfg
файлисточник
Также стоит убедиться, что вы каким-то образом не изменили путь к вашему virtualenv.
В этом случае первая строка в
bin/pip
(и остальные исполняемые файлы) будет иметь неправильный путь.Вы можете либо отредактировать эти файлы и исправить путь, либо удалить и снова установить файл virtualenv.
источник
Для Python 3ers
Попробуйте обновить. У меня была такая же проблема, и я попробовал ответ Чейза, но безуспешно. Самый быстрый способ реорганизовать это - обновить вашу версию Python Minor / Patch, если это возможно. Я заметил, что я работал с 3.5.1 и обновился до 3.5.2. Pyvenv снова работает.
источник
Это случилось со мной, когда я создал virtualenv не в том месте. Затем я подумал, что могу переместить каталог в другое место, неважно. Это имело значение.
О, черт, я забыл сделать cd
projects
перед созданием virtualenv и клонированием репутации. Да ладно, мне лень разрушать и воссоздавать. Я просто переместу каталог без проблем.Нет, нужно больше разрешений, что за? Я думал, что это было странно, но СУДО ПОДАЛИ! Затем он установил пакеты в глобальном расположении.
Урок, который я усвоил, заключался в том, что просто удалите каталог virtualenv. Не двигай его.
источник
Возникла эта проблема после установки Divio: она каким-то образом изменила мой PATH или среду, когда запускает терминал.
Решение в этом случае заключалось в том, чтобы сделать то,
source ~/.bash_profile
что уже должно быть настроено, чтобы вернуть вас в исходное состояние pyenv / pyenv-virtualenv.источник
Это случилось со мной, когда я установил virtualenv с
--python=python3.6
флагом, но потом попытался использоватьpip2 install
.Создание virtualenv с флагом версии, которую вы будете использовать, решает проблемы с разрешениями. Чтобы проверить, попробуйте
which pip
илиwhich pip2
илиwhich pip3
(зависит от вашего выбора). Если какой-либо, которыйpip
вы используете, показывает путь неvenv
здесь, это ваша проблема.источник
Как-то файл setup.cfg с префиксом = "" в папке проекта
запуск pip install на virtualenv вне папки проекта работал так, что изнутри он говорил pip использовать пустой префикс, который по умолчанию равен "/"
удаление файла исправило это
источник
У меня была эта проблема, и, попробовав все вышеуказанное решение, я просто удалил все и начал заново.
В моем собственном случае я использовал
sudo
при создании одной из папок, в которой существовала виртуальная среда, и sudo предоставил привилегии rootЯ был очень зол! Но это сработало!
источник
По какой-то причине мне приходится использовать sudo для установки пакетов через pip в моей системе ubuntu. Это приводит к установке пакетов в глобальные пакеты сайтов. Поместите это здесь для всех, кто может столкнуться с этой проблемой в будущем.
источник
У меня была именно проблема из названия, и я ее решил. Пип начал устанавливаться в пакеты сайта venv после того, как я очистил свой PATH: в самом начале у него был путь к моей локальной директории ~ / bin.
Итак, мой совет: тщательно проверяйте переменные вашего окружения на предмет «мусора» или каких-либо нестандартных вещей. К сожалению, virtualenv может быть чувствителен к ним.
Удачи!
источник
Краткий ответ - запустить команду virtualenv с параметром «-no-site-packages».
Длинный ответ с пояснением: -
Итак, бегая туда-сюда и просматривая множество потоков, я обнаружил, что проблема в себе. Вышеупомянутые ответы дали идею, но я хотел бы снова повторить все.
Проблема в том, что даже если вы активируете среду, она обращается к системной среде из-за того, как мы создали virtualenv.
когда мы запускаем команду virtualenv env -p python3, она устанавливает virtualenv, но не создает глобальный файл site-packages.txt.
Из-за этого, когда вы активируете среду командой source activate, там этот файл с именем site.py (имя может быть другим, я просто забыл), который запускается и проверяет, нет ли этого файла, он не добавит ваш путь env к sys.path и использовать системы python.
чтобы исправить эту проблему, просто запустите virtualenv с дополнительным параметром - no-site-packages, он создаст этот файл, и когда вы активируете среду, он добавит ваш собственный путь к среде в вашу переменную PATH, что сделает его доступным.
источник
Выше было много хороших обсуждений, но были использованы примеры virtualenv. Так как conda теперь является рекомендуемым инструментом для управления virtualenv, я суммировал шаги по запуску pip в conda env следующим образом.
Я буду использовать py36r в качестве имени env, а / opt / conda / envs - это префикс для envs):
Обратите внимание, что исполняемый пункт должен быть в
/opt/conda/envs/py36r/bin/pip
(не/opt/conda/bin/pip
).В качестве альтернативы вы можете просто запустить следующее без активации conda
Также, если вы устанавливаете с помощью conda, вы можете установить без активации:
источник
ОКНА
Для меня решение было не использовать
mkvirtualenv
, а:python -m venv path/to/your/virtualenv
workon работает правильно.
while in virtualenv:
pip -V
показывает путь virtualenv к pipисточник