Python Virtualenv - Kein Modul mit dem Namen "virtualenvwrapper.hook_loader"

Wenn Sie über Macports verfügen, stellen Sie sicher, dass /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin vor /Library/Frameworks/Python.framework/Versions/2.7/bin und /usr/local/bin in PATH aufgeführt ist. Legen Sie dann in Ihrem .profile Folgendes fest:

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

In meinem Fall fügte das Hinzufügen dieser Zeile in meine .zshrc-Datei den Trick ein:

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

Dies ist mir passiert und ich habe es gelöst, indem ich pip neu installierte. Was passiert war, war, dass which pip/usr/bin/pip als Ergebnis gab, während which python/usr/local/bin/python gab. Der Pfad für pip sollte /usr/local/bin/pip sein. Dies ist wahrscheinlich kaputt gegangen, als ich meine Python-Installation aktualisiert habe.

Wenn Sie folgen Sie der Pip-Dokumentation , können Sie pip problemlos für Ihr aktuelles Python-Setup neu installieren. Du musst:

1. Laden Sie das Skript get-pip.py herunter (direkt verbunden mit der Dokumentation von pip).
2. Führen Sie python get-pip.py aus.

Dies hat das Problem für mich gelöst.

Es gibt eine Reihe von Dingen, die diesen Fehler verursachen können. Wenn deine Umgebung ist

• CentOS 7, mit python3 von epel-release installiert
• pip3 installiert mit python3.4 get-pip.py
• virtualenvwrapper installiert mit pip3
• Eine virtuelle Python-Umgebung mit mkvirtualenv -p /usr/bin/python3.4

Dann wird aus irgendeinem Grund die virtuelle Umgebung ohne die Bibliothek von virtualenvwrapper erstellt. Sie können es lösen, indem Sie es einfach erneut installieren

[[email protected] ~] $ 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)[[email protected] ~] $ pip install virtualenvwrapper

Ich musste nur sicherstellen, dass/usr/local/bin/python vorhanden war.

Für mich war es ein einfaches:

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

Für jeden, der Ubuntu 18.04 und Python 3+ verwendet, war dies der Trick für mich: 

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

Ich bekomme den gleichen Fehler. Ich fand heraus, dass ich eine alte Version von Pip hatte. Ich habe den Fehler durch ein einfaches Upgrade des Pip behoben.

Ich hatte das gleiche Problem wie dieses und verbrachte so viel Zeit damit, herauszufinden, was los war. Und ich fand endlich heraus, was los war.

Zuerst habe ich gesucht, wo der Ordner virtualenvwrapper existiert. In meinem Fall /usr/local/lib/python3.7/site-packages. In dem Ordner befindet sich hook_loader.py, das den Fehler verursacht hat.

Als nächstes habe ich python Skript verwendet.

python3

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

Ich konnte das Verzeichnis /usr/local/lib/python3.7/site-packages nicht finden. Endlich schrieb ich:

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

in eine .bashrc-Datei. Erledigt.

Bedeutung von PYTHON PATH

Wie Sie im obigen Link sehen können, erweitert PYTHONPATH den Standardsuchpfad für Module.

Nach der Installation des Conda/Anaconda-Projekts kam es zu einem ähnlichen Problem. Diese Frage war sehr hilfreich bei der Lösung meines Problems unter MAC. Bei der Behebung des Problems hatte mein .zshrc-relevanter Teil so aussehen:

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

Dies hängt davon ab, wo ich die Conda installiert habe, und Sie müssen dies in Ihrem eigenen Fall feststellen. Je nachdem, wo Sie Anaconda installiert haben, können Sie Folgendes für Ihre Umgebung ermitteln:

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

VERGESSEN SIE NICHT, virtualenv und virtualenvwrapper zu deinstallieren und zu installieren, wie in anderen Antworten hervorgehoben.

Ich bin gerade bei einem Centos 7.4 auf dieses Thema gestoßen. 

Keine der obigen Antworten passte zu meinem Fall. Nachdem ich mich ein bisschen herumgegraben hatte, habe ich dies auf zu strenge Dateiberechtigungen in Python-Bibliotheken festgelegt (ich denke, die Python-Installation auf Centos unterscheidet sich ein wenig von anderen POSIX-Systemen).

Wenn alles andere fehlschlägt, möchten Sie möglicherweise prüfen, ob Ihre Python-Bibliotheken für den Benutzer lesbar sind, mit dem Sie den virtualenvwrapper ausführen möchten.

Überprüfen Sie insbesondere: /usr/lib/python3.6 /usr/lib64/python3.6 (Ändern Sie die Pfade für verschiedene Python-Versionen).

Wenn Sie feststellen, dass group und others keine Lese- und Ausführungsberechtigungen enthalten, fügen Sie sie hinzu: Sudo chmod og+rx -R /usr/lib/python3.6 Sudo chmod og+rx -R /usr/lib64/python3.6

Hinweis: Ich bin nicht sicher, ob dies gegen eine Centos-Sicherheitsrichtlinie funktioniert, aber es ist wahrscheinlich sicher, solange Sie nicht write angeben.

Ich habe gerade Python 3.5 installiert, den virtualenvwrapper ausprobiert und hatte dann dieses Problem. Mir wurde klar, dass Python3.5 in /usr/local/bin/python3.5 und NICHT /usr/bin/python3.5 installiert war. Also habe ich mein .bash_profile-Skript überarbeitet, um wie folgt auszusehen, und alles scheint jetzt zu funktionieren 

# 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

Ich bin genug von einem Anfänger, um nicht sicher zu sein, wie sich dieses „Local“ im Pfad zu Python3.5 auf lange Sicht auf mich auswirken wird, aber im Moment funktioniert es.

In meiner Situation (OS X 10.13.6) war dies der Fall

brew install python2 --upgrade

Ich hatte dieses Problem nach uninstalling dem Paket virtualenvwrapper. Wenn ich mich bei einem beliebigen Benutzer angemeldet habe (oder su an einem anderen Benutzer), würde ich Folgendes erhalten:

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.

Die Lösung bestand darin, die /etc/bash_completion.d/virtualenvwrapper-Datei zu löschen.

Bearbeiten:

Löschen Sie die obige Datei nicht oder sie wird nicht neu erstellt, wenn Sie virtualenvwrapper neu installieren. Stattdessen müssen Sie purge das Paket virtualenvwrapper verwenden, wenn Sie es deinstallieren. Auf Debian so:

apt-get remove --purge virtualenvwrapper

Versuchen Sie, Ihre virtualenv und virtualenvwrapper zu deinstallieren und mit pip in Version 2.7 erneut zu installieren (denke ich).

Ich bin auf den gleichen Fehler gestoßen und habe das getan und mein Problem gelöst.

Ich benutze U

Obwohl es eine akzeptierte Antwort gibt, dachte ich, ich würde das, was es für mich fixiert hat, einsetzen.

Zuerst habe ich Python installiert und es gerade aktualisiert über Homebrew . Ich verwende auch ZSH. Wenn also einige Bits nicht ganz mit Ihrer Ausgabe übereinstimmen, könnte dies der Grund dafür sein.

Durch den Aufruf von brew info python und durch das Durchsehen der Ausgabe habe ich die folgenden Informationen von Nice gefunden:

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"

Ich fügte dies wie gezeigt zu meinem Terminalstart-Skript hinzu und der Fehler n wird länger angezeigt.

Hinweis: Ich habe dies in einen anderen Teil meines PATH eingefügt und der Fehler blieb beim Start bestehen.