Python Virtualenv - нет модуля с именем virtualenvwrapper.hook_loader
Я использую Mac OS 10.6.8. и хотел установить в дополнение к Python 2.6 также Python 2.7 и использовать Python 2.7 в новом virtualenv. Я выполнил следующие шаги:
Я скачал Python 2.7 и установил его:
http://www.python.org/ftp/python/2.7.3/python-2.7.3-macosx10.6.dmg
Затем я запускаю команду для установки нового virtualenv с помощью python2.7:
mkvirtualenv --python=python2.7 mynewenv
Мой.bash_profile выглядит следующим образом:
# needed for virtualenvwrapper
export WORKON_HOME=$HOME/.virtualenvs
export VIRTUALENVWRAPPER_PYTHON=/usr/local/bin/python
export VIRTUALENVWRAPPER_VIRTUALENV=/usr/local/bin/virtualenv
source /usr/local/bin/virtualenvwrapper.sh
# Setting PATH for Python 2.7
# The orginal version is saved in .bash_profile.pysave
PATH="/Library/Frameworks/Python.framework/Versions/2.7/bin:${PATH}"
export PATH
Теперь, когда я открываю консоль, я получаю следующее сообщение об ошибке.
ImportError: No module named virtualenvwrapper.hook_loader
virtualenvwrapper.sh: There was a problem running the initialization hooks. If Python could not import the module virtualenvwrapper.hook_loader, check that virtualenv has been installed for VIRTUALENVWRAPPER_PYTHON=/usr/local/bin/python and that PATH is set properly.
Я также нашел в другом посте, что я должен обновить virtualenvwrapper. Это не помогло.
sudo pip install virtualenvwrapper --upgrade
Любая помощь будет оценена.
14 ответов
Проблема была решена, выполнив следующие действия:
#switch the /usr/bin/python link to point to current python link
cd /usr/bin
sudo mv python python.bak
sudo ln -s /Library/Frameworks/Python.framework/Versions/Current/bin/python python
Переставьте команду экспорта так, чтобы она помещалась перед командами virtualenv в моем файле.bash_profile:
PATH=/Library/Frameworks/Python.framework/Versions/2.7/bin:$PATH
export PATH
# needed for virtualenvwrapper
export WORKON_HOME=$HOME/.virtualenvs
source /usr/local/bin/virtualenvwrapper.sh
Переустановите setuptools, легко установите и PIP. Это очевидно необходимо для того, чтобы они правильно работали с новой версией Python:
sudo sh setuptools-0.6c11-py2.7.egg
sudo easy_install-2.7 pip
pip install virtualenv
Кроме того, если у вас есть Macports, убедитесь, что /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin указан ранее /Library/Frameworks/Python.framework/Versions/2.7/bin а также /usr/local/bin в ПУТИ. Затем установите следующее в вас .profile:
export VIRTUALENVWRAPPER_PYTHON=`which python`
export VIRTUALENVWRAPPER_VIRTUALENV=`which virtualenv`
source `which virtualenvwrapper.sh`
Для тех, кто использует Ubuntu 18.04 и Python 3+, это помогло мне:
which python3 # outputs /usr/bin/python3
export VIRTUALENVWRAPPER_PYTHON=/usr/bin/python3
source `which virtualenvwrapper.sh`
В моем случае добавление этой строки в мой файл.zshrc помогло,
export VIRTUALENVWRAPPER_PYTHON=/usr/local/Cellar/python/2.7.13/bin/python2.7
Это случилось со мной, и я решил, переустановив pip, Что случилось, так это то, что which pip дал /usr/bin/pip в результате, пока which python дал /usr/local/bin/python, Путь для pip должно быть /usr/local/bin/pip, Это, вероятно, сломалось, когда я обновил мою установку Python.
Если вы будете следовать документации по пунктам, вы можете легко переустановить pip для вашей текущей рабочей настройки Python. Вам нужно:
- Загрузите скрипт get-pip.py (напрямую связан с
pipдокументация). - Бежать
python get-pip.py,
Это решило проблему для меня.
Есть ряд причин, которые могут вызвать эту ошибку. Если ваша среда
- CentOS 7, с
python3установлен изepel-release pip3установлен сpython3.4 get-pip.pyvirtualenvwrapperустановлен сpip3- Виртуальная среда Python, созданная с
mkvirtualenv -p /usr/bin/python3.4
Затем по какой-либо причине виртуальная среда создается без библиотеки virtualenvwrapper. Вы можете решить это, просто установив его снова, но на этот раз изнутри virtlualenv
[user@localhost ~] $ mkvirtualenv -p /usr/bin/python3.4 venv
Using base prefix '/usr'
New python executable in /home/user/.virtualenvs/venv/bin/python3.4
Also creating executable in /home/user/.virtualenvs/venv/bin/python
Installing setuptools, pip, wheel...done.
virtualenvwrapper.user_scripts creating /home/user/.virtualenvs/venv/bin/predeactivate
virtualenvwrapper.user_scripts creating /home/user/.virtualenvs/venv/bin/postdeactivate
virtualenvwrapper.user_scripts creating /home/user/.virtualenvs/venv/bin/preactivate
virtualenvwrapper.user_scripts creating /home/user/.virtualenvs/venv/bin/postactivate
virtualenvwrapper.user_scripts creating /home/user/.virtualenvs/venv/bin/get_env_details
/home/user/.virtualenvs/venv/bin/python3.4: Error while finding spec for 'virtualenvwrapper.hook_loader' (<class 'ImportError'>: No module named 'virtualenvwrapper')
/home/user/.virtualenvs/venv/bin/python3.4: Error while finding spec for 'virtualenvwrapper.hook_loader' (<class 'ImportError'>: No module named 'virtualenvwrapper')
# the virtualenv should now activated
(venv)[user@localhost ~] $ pip install virtualenvwrapper
Мне просто нужно убедиться, что /usr/local/bin/python существует.
Для меня это было просто:
ln -s /usr/local/bin/python2.7 /usr/local/bin/python
Я получаю ту же ошибку. Узнал, что у меня есть старая версия pip . Я исправил ошибку, просто обновив пункт.
Подобная проблема возникла после установки проекта Conda/Anaconda. Этот вопрос был весьма полезен при решении моей проблемы с MAC. .zshrc соответствующая часть выглядит так:
export VIRTUALENVWRAPPER_PYTHON=$HOME/Applications/conda/bin/python
source $HOME/Applications/conda/bin/virtualenvwrapper.sh
Это зависит от того, где я установил conda, и вам придется выяснить это в вашем собственном случае. Чтобы получить подробности для вашей конкретной среды в зависимости от того, где вы установили anaconda, вы можете использовать следующее:
$ ~/ -name virtualenvwrapper.sh # to see where you have this. May already be prefilled in your shell profile[.zshrc or .profile]
$ which python # to know the default python your project or rather where conda has installed python for you
НЕ ЗАБУДЬТЕ УДАЛИТЬ И УСТАНОВИТЬ virtualenv и virtualenvwrapper, как отмечено в других ответах.
У меня была эта проблема после удаления virtualenvwrapper пакет. Когда я вошел в систему к любому пользователю (или su к другому), я бы получил:
Traceback (most recent call last):
File "<string>", line 1, in <module>
ImportError: No module named virtualenvwrapper.hook_loader
virtualenvwrapper.sh: There was a problem running the initialization hooks.
If Python could not import the module virtualenvwrapper.hook_loader,
check that virtualenv has been installed for
VIRTUALENVWRAPPER_PYTHON=/usr/bin/python and that PATH is
set properly.
Решение было удалить /etc/bash_completion.d/virtualenvwrapper файл.
Редактировать:
Не удаляйте вышеуказанный файл, иначе он не будет воссоздан, если вы переустановите virtualenvwrapper, Вместо этого вам нужно purge virtualenvwrapper пакет, когда вы удалите его. Вот так на Debian:
apt-get remove --purge virtualenvwrapper
У меня была та же проблема, что и у этой, и я потратил так много времени на настройку того, что было не так. И я наконец узнал, что случилось.
Сначала я искал, где находится папка virtualenvwrapper. В моем случае /usr/local/lib/python3.7/site-packages. Внутри папки есть hook_loader.py, который вызвал ошибку.
Далее я использовал скрипт Python.
python3
import sys;print('\n'.join(sys.path))
Я не смог найти каталог /usr/local/lib/python3.7/site-packages, поэтому, наконец, я написал:
export PYTHONPATH=$PYTHONPATH:/usr/local/lib/python3.7/site-packages
в файл.bashrc. Готово.
Как видно из приведенной выше ссылки, PYTHONPATH расширяет путь поиска модулей по умолчанию.
В моей ситуации (OS X 10.13.6) это сделал
brew install python2 --upgrade
Просто столкнулся с этой проблемой на Centos 7.4.
Ни один из приведенных выше ответов не подходит для моего случая. После долгих размышлений я определил это слишком жесткими правами доступа к файлам в библиотеках Python (я полагаю, установка Python в Centos немного отличается от других систем POSIX).
Так что, если все остальное терпит неудачу, вы можете проверить, что ваши библиотеки Python читаются пользователем, с которым вы пытаетесь запустить virtualenvwrapper.
В частности проверьте:
/usr/lib/python3.6
/usr/lib64/python3.6
(изменить пути для разных версий Python).
Если вы видите, что group а также others там нет прав на чтение и выполнение, затем добавьте их:
sudo chmod og+rx -R /usr/lib/python3.6
sudo chmod og+rx -R /usr/lib64/python3.6
Примечание: я не уверен, работает ли это против политики безопасности Centos, но это, вероятно, безопасно, если вы не дадите write persmisions.
Я только что установил python 3.5, попробовал virtualenvwrapper и затем столкнулся с этой проблемой. Я понял, что python3.5 был установлен в /usr/local/bin/python3.5 и не /usr/bin/python3.5, Итак, я изменил свой скрипт.bash_profile, чтобы он выглядел следующим образом, и теперь все работает
# Setting PATH for Python 3.5
# The orginal version is saved in .bash_profile.pysave
PATH="/Library/Frameworks/Python.framework/Versions/3.5/bin:${PATH}"
export PATH
export VIRTUALENVWRAPPER_PYTHON=/usr/local/bin/python3.5
export WORKON_HOME=$HOME/.virtualenvs
source /Users/bentaub/.virtualenvs/djangodev/bin/virtualenvwrapper.sh
Мне достаточно новичка, чтобы не быть уверенным, как этот "локальный" путь к python3.5 повлияет на меня в долгосрочной перспективе, но пока он работает.
Попробуйте удалить свой virtualenv а также virtualenvwrapper и установите его снова, используя pip в версии 2.7 (думаю).
Я столкнулся с той же ошибкой, и я просто сделал это и решил свою проблему.
Я использую U
Даже при том, что есть принятый ответ, я думал, что поставлю то, что исправило это для меня
Сначала я установил Python и только что обновил его через Homebrew. Я также использую ZSH, поэтому, если некоторые биты не совсем соответствуют вашему выводу, возможно, поэтому.
Запустив brew info python и просмотрев вывод, я нашел следующую полезную информацию:
If you wish to have this formula's python executable in your PATH then add
the following to ~/.zshrc:
export PATH="/usr/local/opt/python/libexec/bin:$PATH"
Поэтому я добавил это в свой скрипт запуска терминала, как показано, и ошибка больше не отображается.
Примечание: я вставил это в другую часть моего PATH, и ошибка сохранилась при запуске.