J'utilise Mac OS 10.6.8. et je voulais installer en plus de python 2.6 également python 2.7 et utiliser python 2.7 dans un nouveau virtualenv. J'ai exécuté les étapes suivantes:
J'ai téléchargé Python 2.7 et l'ai installé:
http://www.python.org/ftp/python/2.7.3/python-2.7.3-macosx10.6.dmg
Ensuite, je lance la commande pour configurer un nouveau virtualenv à l’aide de python2.7:
mkvirtualenv --python=python2.7 mynewenv
Mon .bash_profile ressemble à ceci:
# 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
Maintenant, lorsque j'ouvre la console, le message d'erreur suivant s'affiche.
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.
J'ai également découvert dans un autre article que je devrais mettre à niveau virtualenvwrapper. Cela n'a pas aidé.
Sudo pip install virtualenvwrapper --upgrade
Toute aide serait appréciée.
Le problème a été résolu en suivant les étapes ci-dessous:
#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
Réorganisez la commande d'exportation afin qu'elle soit placée avant les commandes virtualenv dans mon fichier .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
Réinstallez setuptools, easy install et PIP. Ceci est évidemment nécessaire pour qu'ils fonctionnent correctement avec la nouvelle version de Python:
Sudo sh setuptools-0.6c11-py2.7.Egg
Sudo easy_install-2.7 pip
pip install virtualenv
De plus, si vous avez des macports, assurez-vous que /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin
figure avant /Library/Frameworks/Python.framework/Versions/2.7/bin
et /usr/local/bin
dans PATH. Puis définissez ce qui suit dans .profile
:
export VIRTUALENVWRAPPER_PYTHON=`which python`
export VIRTUALENVWRAPPER_VIRTUALENV=`which virtualenv`
source `which virtualenvwrapper.sh`
Dans mon cas, l'ajout de cette ligne dans mon fichier .zshrc a fait l'affaire,
export VIRTUALENVWRAPPER_PYTHON=/usr/local/Cellar/python/2.7.13/bin/python2.7
Cela m'est arrivé et je l'ai résolu en réinstallant pip
. Ce qui est arrivé est que which pip
a donné /usr/bin/pip
à la suite, alors que which python
a donné /usr/local/bin/python
. Le chemin pour pip
devrait être /usr/local/bin/pip
. Cela est probablement tombé en panne lorsque j'ai mis à jour mon installation Python.
Si vous suivez la documentation pip vous pouvez facilement réinstaller pip
pour votre configuration Python en cours de fonctionnement. Tu dois:
pip
).python get-pip.py
.Cela a résolu le problème pour moi.
Un certain nombre de facteurs peuvent provoquer cette erreur. Si votre environnement est
python3
installé à partir de epel-release
pip3
installé avec python3.4 get-pip.py
virtualenvwrapper
installé avec pip3
mkvirtualenv -p /usr/bin/python3.4
Ensuite, pour une raison quelconque, l'environnement virtuel est créé sans la bibliothèque virtualenvwrapper. Vous pouvez le résoudre simplement en l'installant à nouveau, mais cette fois dans le 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
Je devais juste m'assurer que/usr/local/bin/python existait.
Pour moi, c'était simple:
ln -s /usr/local/bin/python2.7 /usr/local/bin/python
Pour ceux qui utilisent Ubuntu 18.04 et Python 3+ , cela a été décisif
which python3 # outputs /usr/bin/python3
export VIRTUALENVWRAPPER_PYTHON=/usr/bin/python3
source `which virtualenvwrapper.sh`
J'ai la même erreur . J'ai découvert que j'avais l'ancienne version de pip. J'ai corrigé l'erreur en mettant simplement à niveau le pip.
J'ai eu le même problème que celui-ci et j'ai passé beaucoup de temps à configurer ce qui n'allait pas. Et j'ai finalement découvert ce qui n'allait pas.
J'ai d'abord cherché où le dossier virtualenvwrapper existe. Dans mon cas, /usr/local/lib/python3.7/site-packages. Dans le dossier se trouve hook_loader.py qui a causé l'erreur.
Ensuite, j'ai utilisé le script python.
python3
import sys;print('\n'.join(sys.path))
Je n'ai pas trouvé le répertoire /usr/local/lib/python3.7/site-packages, alors, j'ai enfin écrit:
export PYTHONPATH=$PYTHONPATH:/usr/local/lib/python3.7/site-packages
au fichier .bashrc. Terminé.
Comme vous pouvez le voir dans le lien ci-dessus, PYTHONPATH augmente le chemin de recherche par défaut des modules.
Couru dans un problème similaire après l'installation du projet Conda/Anaconda. Cette question m'a été très utile pour résoudre mon problème sous MAC.Le problème relatif à mon .zshrc
ressemblant à ceci ressemblait à ceci:
export VIRTUALENVWRAPPER_PYTHON=$HOME/Applications/conda/bin/python
source $HOME/Applications/conda/bin/virtualenvwrapper.sh
Cela dépend de l'endroit où j'ai installé Conda et vous devrez le comprendre dans votre cas. Pour obtenir les spécificités de votre environnement donné en fonction de l'installation d'Anaconda, vous pouvez utiliser les éléments suivants:
$ ~/ -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
N'OUBLIEZ PAS DE DÉSINSTALLER ET D'INSTALLER virtualenv et virtualenvwrapper, comme indiqué dans d'autres réponses.
Je viens de tomber sur cette question sur un Centos 7.4.
Aucune des réponses ci-dessus ne convenait à mon cas. Après avoir fouillé un peu, j'ai repéré ce problème avec des autorisations de fichiers trop strictes dans les bibliothèques python (je suppose que l'installation de python sur Centos diffère un peu des autres systèmes POSIX).
Donc, si tout le reste échoue, vous voudrez peut-être vérifier que vos bibliothèques python sont lisibles par l'utilisateur avec lequel vous essayez d'exécuter virtualenvwrapper.
En particulier, vérifiez:
/usr/lib/python3.6
/usr/lib64/python3.6
(Modifiez les chemins pour différentes versions de python).
Si vous voyez que group
et others
ne disposent pas des autorisations de lecture et d'exécution correspondantes, ajoutez-les:
Sudo chmod og+rx -R /usr/lib/python3.6
Sudo chmod og+rx -R /usr/lib64/python3.6
Remarque: Je ne sais pas si cela va à l’encontre d’une politique de sécurité Centos, mais c’est probablement sans danger tant que vous ne donnez pas de modifications write
.
Je viens d'installer Python 3.5, d'essayer le virtualenvwrapper puis de rencontrer ce problème. J'ai réalisé que python3.5 était installé dans /usr/local/bin/python3.5
et NOT /usr/bin/python3.5
. J'ai donc révisé mon script .bash_profile pour qu'il ressemble à ce qui suit et tout semble fonctionner maintenant
# 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
Je suis assez novice pour ne pas savoir en quoi ce 'local' sur le chemin de python3.5 va m'affecter à long terme mais, pour le moment, cela fonctionne.
Dans ma situation (OS X 10.13.6), cela l’a fait
brew install python2 --upgrade
J'ai eu ce problème après désinstaller le package virtualenvwrapper
. Quand je me connectais à n'importe quel utilisateur (ou su
à un autre), j'obtenais:
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.
La solution consistait à supprimer le fichier /etc/bash_completion.d/virtualenvwrapper
.
Modifier:
Ne supprimez pas le fichier ci-dessus ou il ne sera pas recréé si vous réinstallez virtualenvwrapper
. Ce que vous devez faire, c'est plutôt purge
le package virtualenvwrapper
lorsque vous le désinstallez. Comme ceci sur Debian:
apt-get remove --purge virtualenvwrapper
Essayez de désinstaller votre virtualenv
et virtualenvwrapper
et réinstallez-le en utilisant pip
dans la version 2.7 (je pense).
J'ai rencontré la même erreur et je viens de faire cela et résolu mon problème.
J'utilise U
Même s'il y a une réponse acceptée, je pensais mettre ce qui était réglé pour moi.
Premièrement, j'ai installé Python et je venais de le mettre à jour via Homebrew . J'utilise aussi ZSH, donc si certains bits ne correspondent pas vraiment à votre sortie, c'est peut-être pour cela.
En exécutant brasser les informations python et en parcourant la sortie, j'ai trouvé les informations suivantes:
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"
J'ai donc ajouté ceci à mon script de démarrage de terminal, comme indiqué, et l'erreur n ne s'affiche plus.
Remarque: je l'ai inséré dans une autre partie de PATH et l'erreur a persisté au démarrage.