Python Virtualenv - brak modułu o nazwie virtualenvwrapper.hook_loader

Używam systemu Mac OS 10.6.8. i chciałem zainstalować oprócz pythona 2.6 także python 2.7 i używać pythona 2.7 w nowym virtualenv. Wykonałem następujące kroki:

Pobrałem Pythona 2.7 i zainstalowałem go:

http://www.python.org/ftp/python/2.7.3/python-2.7.3-macosx10.6.dmg

Następnie uruchamiam polecenie, aby skonfigurować nowy virtualenv za pomocą python2.7:

mkvirtualenv --python=python2.7 mynewenv

Mój .bash_profile wygląda następująco:

# 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

Teraz, kiedy otwieram konsolę, pojawia się następujący komunikat o błędzie.

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.

Znalazłem też w innym poście, że powinienem zaktualizować virtualenvwrapper. To nie pomogło.

sudo pip install virtualenvwrapper --upgrade

Każda pomoc będzie mile widziana.

Problem został rozwiązany, wykonując poniższe czynności:

#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

Przeorganizuj polecenie eksportu, aby było umieszczone przed poleceniami virtualenv w moim pliku .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

Ponownie zainstaluj narzędzia setup, łatwa instalacja i PIP. Jest to oczywiście potrzebne, aby działały poprawnie z nową wersją Pythona:

sudo sh setuptools-0.6c11-py2.7.egg

sudo easy_install-2.7 pip

pip install virtualenv

Ponadto, jeśli masz macport, upewnij się, że /opt/local/Library/Frameworks/Python.framework/Versions/2.7/binjest wymieniony przed /Library/Frameworks/Python.framework/Versions/2.7/bini /usr/local/binw PATH. Następnie ustaw w sobie .profile:

export VIRTUALENVWRAPPER_PYTHON=`which python`
export VIRTUALENVWRAPPER_VIRTUALENV=`which virtualenv`
source `which virtualenvwrapper.sh`

W moim przypadku dodanie tej linii do mojego pliku .zshrc załatwiło sprawę,

export VIRTUALENVWRAPPER_PYTHON=/usr/local/Cellar/python/2.7.13/bin/python2.7

Dla każdego, kto używa Ubuntu 18.04 i Python 3+ , załatwiło to dla mnie:

which python3 # outputs /usr/bin/python3 
export VIRTUALENVWRAPPER_PYTHON=/usr/bin/python3  
source `which virtualenvwrapper.sh`  

Przydarzyło mi się to i rozwiązałem to, ponownie instalując pip. To, co się wydarzyło, which pipdawało /usr/bin/pipw rezultacie, a which pythondawało /usr/local/bin/python. Droga do pippowinna być /usr/local/bin/pip. Prawdopodobnie zepsuło się to, gdy zaktualizowałem instalację Pythona.

Jeśli będziesz postępować zgodnie z dokumentacją pip , możesz łatwo ponownie zainstalować pipbieżącą działającą konfigurację Pythona. Musisz:

1. Pobierz skrypt get-pip.py (bezpośrednio połączony zpip dokumentacją).
2. Biegnij python get-pip.py.

To rozwiązało problem.

Istnieje wiele przyczyn, które mogą powodować ten błąd. Jeśli twoje środowisko jest

• CentOS 7, z python3zainstalowanym zepel-release
• pip3 zainstalowany z python3.4 get-pip.py
• virtualenvwrapper zainstalowany z pip3
• Środowisko wirtualne Pythona utworzone w programie mkvirtualenv -p /usr/bin/python3.4

Następnie, z dowolnego powodu, środowisko wirtualne jest tworzone bez biblioteki virtualenvwrapper. Możesz go rozwiązać, po prostu instalując go ponownie, ale tym razem z poziomu 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

Musiałem się tylko upewnić, że istnieje / usr / local / bin / python.

Dla mnie to było proste:

ln -s /usr/local/bin/python2.7 /usr/local/bin/python

Otrzymuję ten sam błąd. Dowiedziałem się, że mam starą wersję pip. Naprawiłem błąd, po prostu aktualizując pip.

Właśnie zainstalowałem Pythona 3.5, wypróbowałem virtualenvwrapper i miałem ten problem. Zdałem sobie sprawę, że python3.5 został zainstalowany /usr/local/bin/python3.5i NIE /usr/bin/python3.5. Więc poprawiłem mój skrypt .bash_profile, aby wyglądał następująco i teraz wszystko wydaje się działać

# 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

Jestem na tyle nowicjuszem, że nie jestem pewien, jak to „lokalne” w ścieżce do pythona 3.5 wpłynie na mnie na dłuższą metę, ale na razie działa.

Miałem ten problem po odinstalowaniu ten virtualenvwrapperpakiet. Gdy logowałem się do dowolnego użytkownika (lub suinnego), otrzymywałem:

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.

Rozwiązaniem było usunięcie /etc/bash_completion.d/virtualenvwrapperpliku.

Edytować:

Nie usuwaj powyższego pliku lub nie zostanie on odtworzony po ponownej instalacji virtualenvwrapper. Zamiast tego, co trzeba zrobić, to pakiet kiedy go odinstalować. Tak jak w Debianie:purgevirtualenvwrapper

apt-get remove --purge virtualenvwrapper

Spróbuj odinstalować virtualenvi virtualenvwrapperi zainstalować go ponownie, korzystającpip w wersji 2.7 (chyba).

Napotkałem ten sam błąd i właśnie to zrobiłem i rozwiązałem swój problem.

Używam U

Chociaż istnieje akceptowana odpowiedź, pomyślałem, że umieściłem to, co naprawiło to dla mnie.

Najpierw zainstalowałem Pythona i właśnie zaktualizowałem go przez Homebrew . Używam również ZSH, więc jeśli niektóre bity nie pasują do twoich danych wyjściowych, może to być przyczyna.

Uruchamiając brew info python i przeglądając dane wyjściowe, znalazłem następującą niezłą informację:

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"

Więc dodałem to do mojego skryptu startowego terminala, jak pokazano, a błąd n już się wyświetla.

Uwaga: wstawiłem to do innej części mojej PATH i błąd nadal występował podczas uruchamiania.

Po zainstalowaniu projektu Conda / Anaconda napotkałem podobny problem. To pytanie było bardzo pomocne w rozwiązaniu mojego problemu na MAC.Rozwiązanie problemu sprawiło, że moja .zshrcodpowiednia część wyglądała tak:

export VIRTUALENVWRAPPER_PYTHON=$HOME/Applications/conda/bin/python
source $HOME/Applications/conda/bin/virtualenvwrapper.sh

Zależy to od tego, gdzie zainstalowałem condę i będziesz musiał to obliczyć w swoim własnym przypadku. Aby uzyskać szczegółowe informacje dla danego środowiska, w zależności od tego, gdzie zainstalowałeś anakondę, możesz użyć następujących opcji:

$  ~/ -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

NIE ZAPOMNIJ ODINSTALOWAĆ I ZAINSTALOWAĆ virtualenv i virtualenvwrapper, jak podkreślono w innych odpowiedziach.

Właśnie natknąłem się na ten problem na Centos 7.4.

Żadna z powyższych odpowiedzi nie pasowała do mojego przypadku. Po dłuższym przekopaniu się, wskazałem na zbyt restrykcyjne uprawnienia do plików w bibliotekach Pythona (wydaje mi się, że instalacja pythona na Centos różni się nieco od innych systemów POSIX).

Tak więc, jeśli wszystko inne zawiedzie, możesz chcieć sprawdzić, czy twoje biblioteki Pythona są czytelne dla użytkownika, z którym próbujesz uruchomić virtualenvwrapper.

W szczególności sprawdź: /usr/lib/python3.6 /usr/lib64/python3.6 (popraw ścieżki dla różnych wersji Pythona).

Jeśli to widzisz groupi othersnie masz uprawnień do odczytu i wykonywania, dodaj je: sudo chmod og+rx -R /usr/lib/python3.6 sudo chmod og+rx -R /usr/lib64/python3.6

Uwaga: nie jestem pewien, czy działa to przeciwko polityce bezpieczeństwa Centos, ale prawdopodobnie jest to bezpieczne, o ile nie dasz writepersmisji.

W mojej sytuacji (OS X 10.13.6) to wystarczyło

brew install python2 --upgrade

Miałem ten sam problem, co ten i spędziłem dużo czasu na konfigurowaniu tego, co było nie tak. I w końcu dowiedziałem się, co się stało.

Najpierw szukałem, gdzie istnieje folder virtualenvwrapper. W moim przypadku /usr/local/lib/python3.7/site-packages. Wewnątrz folderu znajduje się hook_loader.py, który spowodował błąd.

Następnie użyłem skryptu Python.

python3

import sys;print('\n'.join(sys.path))

Nie mogłem znaleźć katalogu /usr/local/lib/python3.7/site-packages, więc w końcu napisałem:

export PYTHONPATH=$PYTHONPATH:/usr/local/lib/python3.7/site-packages

do pliku .bashrc. Gotowe.

Znaczenie PYTHON PATH

Jak widać w powyższym linku, PYTHONPATH rozszerza domyślną ścieżkę wyszukiwania modułów.