Ningún módulo llamado ‘virtualenvwrapper’

Estoy trabajando para configurar un proyecto Django en Amazon EC2 con una instancia de Ubuntu 14.04 LTS. Quiero escribir mi código usando Python 3. Me han dicho que la mejor manera de hacerlo es usar virtualenvwrapper . He instalado virtualenvwrapper éxito y poner

 export WORKON_HOME=$HOME/.virtualenvs export VIRTUALENVWRAPPER_PYTHON=/usr/bin/python3.4 export PROJECT_HOME=$HOME/Devel source /usr/local/bin/virtualenvwrapper.sh 

en mi archivo .bashrc . Ahora veo:

  /usr/bin/python3.4: Error while finding spec for 'virtualenvwrapper.hook_loader' (: No module named 'virtualenvwrapper') virtualenvwrapper.sh: There was a problem running the initialization hooks. If Python could not import the module virtualenvwrapper.hook_loader, check that virtualenvwrapper has been installed for VIRTUALENVWRAPPER_PYTHON=/usr/bin/python3.4 and that PATH is set properly. 

¿Cómo puedo arreglar esto?

En lugar de especificar un intérprete de python diferente con el indicador -p , también puede configurar el intérprete deseado como predeterminado.

De acuerdo con la documentación de virtualenvwrapper.sh , virtualenvwrapper.sh encuentra los primeros progtwigs python y virtualenv en $PATH y los recuerda para usarlos más adelante.

Si su virtualenvwrapper no está instalado en el intérprete de python predeterminado de su sistema operativo ( /usr/bin/python ), asegúrese de anular las variables de entorno de la siguiente manera:

  • VIRTUALENVWRAPPER_PYTHON a la ruta completa de su intérprete de python
  • VIRTUALENVWRAPPER_VIRTUALENV a la ruta completa de virtualenv

Por ejemplo, en mi .bash_profile (Mac):

 #virtualenvwrapper export WORKON_HOME=$HOME/.virtualenvs export VIRTUALENVWRAPPER_PYTHON=/Library/Frameworks/Python.framework/Versions/3.5/bin/python3 export VIRTUALENVWRAPPER_VIRTUALENV=/Library/Frameworks/Python.framework/Versions/3.5/bin/virtualenv source /Library/Frameworks/Python.framework/Versions/3.5/bin/virtualenvwrapper.sh 

Recarga tus nuevas variables ejecutando source ~/.bash_profile

Tuve el mismo problema después de las recientes actualizaciones de Homebrew.

En el pasado, la mayoría de las personas habrían ejecutado pip install virtualenvwrapper en los paquetes del sitio del sistema y habría funcionado.

Homebrew interrumpió este flujo de trabajo por 1) ya no sombreado el sistema python, y 2) ya no está sincronizando pip con pip2/pip3 .

La mayoría de los usuarios se darán cuenta de esto cuando no puedan encontrar pip y luego intentarán usar pip2/pip3 . Sin embargo, utilizar pip2/pip3 creará un problema porque virtualenvwrapper ahora está instalado para python2/python3 , pero no para python . Entonces, cuando virtualenvwrapper ejecuta y llama python, no encontrará los paquetes virtualenvwrapper/virtualenv python en los paquetes de sitio de python del sistema.

Establecer explícitamente VIRTUALENVWRAPPER_PYTHON es la solución más limpia, y no un hack. Así es como lo hice en mis dotfiles.

 export VIRTUALENVWRAPPER_PYTHON=/usr/local/bin/python3 

Si usa brew para instalar python, querrá asegurarse de que establece esta variable de entorno:

 export VIRTUALENVWRAPPER_PYTHON=/usr/local/bin/python 

en su perfil bash (o cualquier shell que esté usando).

Siguiendo el consejo de Jon, corrí:

  ubuntu@ip-172-31-22-65:~$ mkvirtualenv -p /usr/bin/python3.4 env1 Running virtualenv with interpreter /usr/bin/python3.4 Using base prefix '/usr' New python executable in env1/bin/python3.4 Also creating executable in env1/bin/python Installing setuptools, pip...done. (env1)ubuntu@ip-172-31-22-65:~$ deactivate ubuntu@ip-172-31-22-65:~$ ls ubuntu@ip-172-31-22-65:~$ ls -a . .. .bash_history .bash_logout .bashrc .cache .pip .profile .ssh .virtualenvs ubuntu@ip-172-31-22-65:~$ workon env1 ubuntu@ip-172-31-22-65:~$ workon env1 (env1)ubuntu@ip-172-31-22-65:~$ which python /home/ubuntu/.virtualenvs/env1/bin/python (env1)ubuntu@ip-172-31-22-65:~$ python -V Python 3.4.0 

He dejado el .bashrc como se indica arriba. Como Jon indicó anteriormente, instalar las instalaciones de virtualenvwrapper en el python predeterminado, y usa el python predeterminado en cualquier virtualenv que cree, a menos que se use la marca -p para especificar un intérprete de python diferente.

¡Gracias Jon!