instalar - macos python virtual environment

Referencias rotas en Virtualenvs

Question

Recientemente instalé un montón de archivos dot en mi Mac junto con algunas otras aplicaciones (cambié a iTerm en lugar de Terminal y Sublime como mi editor de texto predeterminado) pero desde entonces, todos mis entornos virtuales han dejado de funcionar, aunque sus carpetas están dentro de .virtualenvs todavía están allí y dan el siguiente error cada vez que intento ejecutar algo en ellos:

dyld: Library not loaded: @executable_path/../.Python
  Referenced from: /Users/[user]/.virtualenvs/modclass/bin/python
  Reason: image not found
Trace/BPT trap: 5

He eliminado todos los archivos relacionados con dotfiles y he restaurado mi archivo .bash_profile a lo que era antes, pero el problema persiste. ¿Hay alguna manera de diagnosticar el problema o resolverlo de una manera fácil (por ejemplo, sin tener que volver a crear todos los virtualenvs)?

Answer 1

Después de probar algunas cosas, esto funcionó para mí:

vaya a su directorio virtualenv (pero no ejecute workon):

cd ~/.virtualenv/name_of_broken_venv

Ahora borre estos archivos:

rm -rf .Python bin/python* lib/python2.7/* include/python2.7

Luego, para reconstruir tu venv, ejecuta:

virtualenv .
workon name_of_broken_venv
pip freeze

Ahora debería ver una lista de sus paquetes instalados nuevamente.

Answer 2

Esto ocurrió cuando actualicé a Mac OS X Mavericks de Snow Leopard. Tuve que volver a instalar brebaje de antemano también. Esperemos que hayas ejecutado el comando de congelación para tu proyecto con pip.

Para resolverlo, debe actualizar las rutas a las que apunta el entorno virtual.

• Instale una versión de python con brew:

brew install python

• Reinstalar virtualenvwrapper.

pip install --upgrade virtualenvwrapper

• Se eliminó el antiguo entorno virtual:

rmvirtualenv old_project

• Crea un nuevo entorno virtual:

mkvirtualenv new_project

• Trabajar en un nuevo entorno virtual

workon new_project

• Use pip para instalar los requisitos para el nuevo proyecto.

pip install -r requirements.txt

Esto debería dejar el proyecto como estaba antes.

Answer 3

La respuesta aceptada no funciona para mí: el archivo $WORKON_HOME/*/bin/python2.7 ya no es un enlace simbólico, es un ejecutable hecho y derecho:

$ file $WORKON_HOME/*/bin/python2.7
/Users/sds/.virtualenvs/.../bin/python2.7: Mach-O 64-bit executable x86_64
...

La solución es, por desgracia, eliminar por completo y volver a crear desde cero todos los entornos virtuales.

Para la referencia:

deactivate
pip install --user virtualenv virtualenvwrapper
pip install --user --upgrade virtualenv virtualenvwrapper
for ve in $(lsvirtualenv -b); do
  # assume that each VE is associated with a project
  # and the project has the requirements.txt file
  project=$(cat $WORKON_HOME/$ve/.project)
  rmvirtualenv $ve
  mkvirtualenv -a $project -r requirements.txt $ve
done

Answer 4

Si has arrestado a python3, prueba brew upgrade python3 que lo arregló por mí.

Answer 5

Una versión de actualización @Chris Wedgwood es la respuesta para mantener site-packages (mantener los paquetes instalados)

cd ~/.virtualenv/name_of_broken_venv


mv lib/python2.7/site-packages ./    
rm -rf .Python bin lib include
virtualenv .
rm -rf lib/python2.7/site-packages
mv ./site-packages lib/python2.7/

Answer 6

Usando Python 2.7.10.

Un solo comando virtualenv path-to-env hace. documentation

$ virtualenv path-to-env
Overwriting path-to-env/lib/python2.7/orig-prefix.txt with new content
New python executable in path-to-env/bin/python2.7
Also creating executable in path-to-env/bin/python
Installing setuptools, pip, wheel...done.

Answer 7

Parece que la forma correcta de resolver este problema es ejecutar

 pip install --upgrade virtualenv

después de haber actualizado Python con Homebrew.

Este debería ser un procedimiento general para cualquier fórmula que instale algo así como python, que tiene su propio sistema de administración de paquetes. Cuando instala brew install python , instala python y pip y easy_install y virtualenv y así sucesivamente. Entonces, si esas herramientas se pueden actualizar automáticamente, lo mejor es tratar de hacerlo antes de considerar a Homebrew como la fuente de los problemas.

Answer 8

here encontré la solución al problema, por lo que todo el mérito recae en el autor.

Lo esencial es que cuando se crea un virtualenv, se crean muchos enlaces simbólicos al Python instalado en Homebrew.

Aquí hay un ejemplo:

$ ls -la ~/.virtualenvs/my-virtual-env
...
lrwxr-xr-x  1 ryan staff   78 Jun 25 13:21 .Python -> /usr/local/Cellar/python/2.7.7/Frameworks/Python.framework/Versions/2.7/Python
...

Cuando actualiza Python usando Homebrew y luego ejecuta la brew cleanup , los enlaces simbólicos en el virtualenv apuntan a rutas que ya no existen (porque Homebrew las eliminó).

Los enlaces simbólicos deben apuntar a la Python recién instalada:

lrwxr-xr-x  1 ryan staff   78 Jun 25 13:21 .Python -> /usr/local/Cellar/python/2.7.8_1/Frameworks/Python.framework/Versions/2.7/Python

La solución es eliminar los enlaces simbólicos en el virtualenv y luego recrearlos:

find ~/.virtualenvs/my-virtual-env/ -type l -delete
virtualenv ~/.virtualenvs/my-virtual-env

Probablemente sea mejor verificar qué enlaces se eliminarán primero antes de eliminarlos:

find ~/.virtualenvs/my-virtual-env/ -type l

En mi opinión, es incluso mejor eliminar solo enlaces simbólicos rotos. Puedes hacer esto usando GNU find :

gfind ~/.virtualenvs/my-virtual-env/ -type l -xtype l -delete

Puede instalar GNU find con Homebrew si aún no lo tiene:

brew install findutils

Tenga en cuenta que, de forma predeterminada, los programas de GNU instalados con Homebrew tienden a tener el prefijo con la letra g . Esto es para evitar sombrear el binario de find que se envía con OS X.