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.
python
virtualenv
virtualenvwrapper
Thomas Kremmel
źródło
źródło
easy_install
mkvirtualenv
a 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 samomkvirtualenv
polecenie działało poprawnie.Odpowiedzi:
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
źródło
usr/local/Cellar/python/<PYTHON-VERSION>/bin/
.Ponadto, jeśli masz macport, upewnij się, że
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin
jest wymieniony przed/Library/Frameworks/Python.framework/Versions/2.7/bin
i/usr/local/bin
w PATH. Następnie ustaw w sobie.profile
:źródło
VIRTUALENVWRAPPER_PYTHON
rozwiązało mój problem.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
źródło
export VIRTUALENVWRAPPER_PYTHON=/usr/local/Cellar/python/3.6.5/bin/python3.6
dla najnowszej wersji.export VIRTUALENVWRAPPER_PYTHON="which python3"
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`
źródło
Przydarzyło mi się to i rozwiązałem to, ponownie instalując
pip
. To, co się wydarzyło,which pip
dawało/usr/bin/pip
w rezultacie, awhich python
dawało/usr/local/bin/python
. Droga dopip
powinna 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ć
pip
bieżącą działającą konfigurację Pythona. Musisz:pip
dokumentacją).python get-pip.py
.To rozwiązało problem.
źródło
Istnieje wiele przyczyn, które mogą powodować ten błąd. Jeśli twoje środowisko jest
python3
zainstalowanym zepel-release
pip3
zainstalowany zpython3.4 get-pip.py
virtualenvwrapper
zainstalowany zpip3
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
źródło
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
źródło
Otrzymuję ten sam błąd. Dowiedziałem się, że mam starą wersję pip. Naprawiłem błąd, po prostu aktualizując pip.
źródło
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.5
i 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.
źródło
Miałem ten problem po odinstalowaniu ten
virtualenvwrapper
pakiet. Gdy logowałem się do dowolnego użytkownika (lubsu
innego), 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/virtualenvwrapper
pliku.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:purge
virtualenvwrapper
źródło
Spróbuj odinstalować
virtualenv
ivirtualenvwrapper
i 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
źródło
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.
źródło
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
.zshrc
odpowiednia 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.
źródło
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
group
iothers
nie 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
write
persmisji.źródło
W mojej sytuacji (OS X 10.13.6) to wystarczyło
źródło
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.
źródło