Python Virtualenv - Ningún módulo llamado virtualenvwrapper.cargador de gancho

Además, si tiene macports, asegúrese de que /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin aparece antes de /Library/Frameworks/Python.framework/Versions/2.7/bin y /usr/local/bin en PATH. Luego establece lo siguiente en ti .profile:

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

En mi caso, añadiendo esta línea en mi.archivo zshrc hizo el truco,

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

Esto me sucedió y lo resolví reinstalando pip. Lo que había sucedido era que which pip dio /usr/bin/pip como resultado, mientras que which python dio /usr/local/bin/python. La ruta para pip debe ser /usr/local/bin/pip. Esto probablemente se rompió cuando actualizé mi instalación de Python.

Si sigue la documentación pip puede reinstalar fácilmente pip para su configuración actual de Python. Necesitas:

1. Descargar el get-pip.py script (directamente vinculado desde pip's documentación).
2. Ejecutar python get-pip.py.

Esto resolvió el problema para mí.

Hay una serie de cosas que pueden causar este error. Si su entorno es

• CentOS 7, con python3 instalado desde epel-release
• pip3 instalado con python3.4 get-pip.py
• virtualenvwrapper instalado con pip3
• Un entorno virtual de python hecho con mkvirtualenv -p /usr/bin/python3.4

Entonces, por cualquier razón, el entorno virtual se crea sin la biblioteca virtualenvwrapper. Puede resolverlo simplemente instalándolo de nuevo, pero esta vez desde dentro del 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

Solo tenía que asegurarme de que /usr/local/bin/python existía.

Para mí fue un simple:

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

Obtengo el mismo error . Descubrí que tenía una versión antigua de Pip . Arreglé el error simplemente actualizando el pip .

Acabo de instalar python 3.5,probé el virtualenvwrapper y luego tuve este problema. Me di cuenta de que python3.5 estaba instalado en /usr/local/bin/python3.5 y NO en /usr/bin/python3.5. Así que revisé mi .bash_profile script para parecerse a la siguiente y todo parece funcionar ahora

# 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

Soy lo suficientemente novato como para no estar seguro de cómo ese 'local' en el camino a python3.5 va a afectarme a largo plazo, pero, por ahora, funciona.

Tuve este problema después de desinstalar el paquete virtualenvwrapper. Cuando me conectaba a cualquier usuario (o su a uno diferente), obtenía:

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 solución fue eliminar el archivo /etc/bash_completion.d/virtualenvwrapper.

Editar:

No elimine el archivo anterior o no se volverá a crear si vuelve a instalar virtualenvwrapper. En su lugar, lo que debe hacer es purge el paquete virtualenvwrapper cuando lo desinstale. Así en Debian:

apt-get remove --purge virtualenvwrapper

Intente desinstalar su virtualenv y virtualenvwrapper e instálelo de nuevo usando pip en la versión 2.7 (creo).

Me encontré con el mismo error y acabo de hacer esto y resuelto mi problema.

I usando U

A pesar de que hay una respuesta aceptada, pensé que pondría lo que la arregló para mí.

En primer lugar instalé Python y acababa de actualizarlo a través de Homebrew. También estoy usando ZSH, por lo que si algunos bits no coinciden con su salida, podría ser por eso.

Ejecutando brew info python y mirando a través de la salida encontré la siguiente información:

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"

Así que agregué esto a mi script de inicio de terminal como se muestra y el error n Mostrar.

Nota: Inserté esto en otra parte de mi RUTA y el error persistió al iniciar.

Se encontró con un problema similar después de instalar el proyecto Conda/Anaconda. Esta pregunta fue bastante útil para resolver mi problema en MAC.Para resolver el problema, mi .zshrc porción relevante se veía así:

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

Esto depende de dónde tengo instalado conda y tendrás que calcularlo en tu propio caso. Para obtener los detalles para su entorno dado, dependiendo de dónde haya instalado anaconda, puede usar lo siguiente:

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

NO SE OLVIDE DE DESINSTALAR E INSTALAR virtualenv y virtualenvwrapper como se destaca en otras respuestas.

Acaba de toparse con este problema en un Centos 7.4.

Ninguna de las respuestas anteriores se adaptaba a mi caso. Después de un poco de investigación, señalé esto como permisos de archivo demasiado estrictos en las bibliotecas de python (supongo que la instalación de python en Centos difiere un poco de otros sistemas POSIX).

Por lo tanto, si todo lo demás falla, es posible que desee verificar que sus bibliotecas de python sean legibles por el usuario con el que está tratando de ejecutar virtualenvwrapper.

En particular, comprobar: /usr/lib/python3.6 /usr/lib64/python3.6 (modificar las rutas para diferentes versiones de python).

Si ves que group y others carecen de permisos de lectura y ejecución, entonces agrégalos: sudo chmod og+rx -R /usr/lib/python3.6 sudo chmod og+rx -R /usr/lib64/python3.6

Nota: No estoy seguro de si esto funciona en contra de una política de seguridad de Centos, pero probablemente es seguro siempre y cuando no se da write persmisions.

En mi situación (OS X 10.13.6), esto lo hizo

brew install python2 --upgrade