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

79

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.

Thomas Kremmel
źródło
4
Widziałeś to, czy mógłbyś spróbować inaczejeasy_install
podziwiaj
Dzięki spojrzałem na post. Ale nie mogę zainstalować virtualenv dla Pythona 2.7. Wiadomość jest taka, że ​​virtualenv jest już zainstalowany dla wersji 2.6. Uruchomiłem następujące polecenia: ~ TK $ które python /Library/Frameworks/Python.framework/Versions/2.7/bin/python ~ TK $ sudo pip install virtualenv Wymaganie już spełnione (użyj --upgrade to upgrade): virtualenv w / Library / Python / 2.6 / site-packages / virtualenv-1.6-py2.6.egg Porządkowanie ...
Thomas Kremmel
I właśnie wyglądał virtualenv za stan i to nie wygląda to obsługuje Py 2.7.
martineau
2
Tylko uwaga - trafiłem na ten problem w innym przypadku. Zacząłem tworzyć virtualenv przez, mkvirtualenva potem go zatrzymałem (za pomocą Ctrl+C). Podczas ponownej próby stworzenia virtualenv pozostały resztki z ostatniego razu. Wszedłem do mojego folderu envs i usunąłem niekompletnie zbudowane środowisko. Potem to samo mkvirtualenvpolecenie działało poprawnie.
driftcatcher
2
Komentarz Yibo Yang był również trafiony w przypadku mojej instalacji Ubuntu. Tylko uważaj na pisownię ... powyższe powinno być eksportowane VIRTUALENVWRAPPER_PYTHON = / usr / bin / python3 z "v" w VIRTUALENVWRAPPER
Kevin

Odpowiedzi:

53

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
Thomas Kremmel
źródło
1
Dzięki - po uaktualnieniu mojej instalacji Pythona 2.7 na Mac Mountain Lion miałem ten sam problem i to go naprawiło.
A. Jesse Jiryu Davis,
3
W Mountain Lion sztuką było upewnienie się, że ŚCIEŻKA dla / opt / local / bin została ustawiona PRZED linią źródłową ... Nie musiałem majstrować przy linkach OSX Python w / usr / bin ani nic innego. Również WORKON_HOME jest teraz domyślnie ustawione, jeśli nie jest ustawione na $ HOME / .virtualenvs
Mark
4
+1 dla komentarza @Mark. Również dla użytkowników piwa: rzeczywista ścieżka to usr/local/Cellar/python/<PYTHON-VERSION>/bin/.
rsenna
Dzięki, pomaga mi po skompilowaniu Pythona 2.7.4 w Debianie.
Zulu,
W moim przypadku problem wystąpił tylko dlatego, że próbowałem zalogować się zdalnie na innym komputerze. Wskazówka, oznacza to, że problem nie występuje na komputerze lokalnym, ale na komputerze, na którym się logujesz! Pomyślałem, że wspomnę o tym na wypadek, gdyby ktoś był w tym miejscu.
smileBot
23

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`
reubano
źródło
4
Instaluję python3 wraz z moim systemem operacyjnym python2 i ustawienie VIRTUALENVWRAPPER_PYTHONrozwiązało mój problem.
Johan Gov
8

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
pecai
źródło
3
export VIRTUALENVWRAPPER_PYTHON=/usr/local/Cellar/python/3.6.5/bin/python3.6dla najnowszej wersji.
oba2311
w moim bash_profile,export VIRTUALENVWRAPPER_PYTHON="which python3"
Fai Zal Dong
8

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`  
Kalob Taulien
źródło
4

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.

Omar Trejo
źródło
3

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
drs
źródło
2

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
dustinfarris
źródło
1

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

Chinmay Das
źródło
0

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.

Ben
źródło
0

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
Mikrofon
źródło
0

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

manilaT
źródło
0

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.

Skepi
źródło
0

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.

ArdentLearner
źródło
0

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.


źródło
0

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

brew install python2 --upgrade
Sójka
źródło
0

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.

MeNinLes
źródło