Ubuntu + virtualenv = un lío? virtualenv odia los paquetes dist, quiere paquetes de sitio

¿Puede alguien explicarme qué está pasando con Python en Ubuntu 9.04?

Estoy tratando de girar virtualenv , y la bandera --no-site-packages parece no hacer nada con ubuntu. Instalé virtualenv 1.3.3 con easy_install (que he actualizado a setuptools 0.6c9 ) y todo parece estar instalado en /usr/local/lib/python2.6/dist-packages

Supongo que al instalar un paquete usando apt-get, se coloca en /usr/lib/python2.6/dist-packages/ ?

El problema es que hay un /usr/local/lib/python2.6/site-packages , así que simplemente se queda allí vacío. Parecería (al observar la path en un virtualenv ) que esta es la carpeta que virtualenv usa como respaldo. Por lo tanto, incluso aunque omito --no-site-packages , no puedo acceder a mis paquetes de sistemas locales desde ninguno de mis virtualenv’s.

Así que mis preguntas son:

  1. ¿Cómo puedo hacer que virtualenv apunte a uno de los dist-packages ?
  2. ¿A qué dist-paquetes debo señalarlo? /usr/lib/python2.6/dist-packages o /usr/local/lib/python2.6/dist-packages/
  3. ¿Cuál es el punto de /usr/lib/python2.6/site-packages ? ¡No hay nada ahí dentro!
  4. ¿Primero es el primero en servir en el camino? Si tengo una versión más nueva del paquete XYZ instalado en /usr/local/lib/python2.6/dist-packages/ y una versión anterior (de ubuntu repos / apt-get) en /usr/lib/python2.6/dist-packages , ¿cuál se importa cuando import xyz ? Supongo que esto se basa en la lista de rutas, ¿sí?
  5. ¿Por qué diablos es esto tan confuso? ¿Hay algo que me estoy perdiendo aquí?
  6. ¿Dónde está definido que easy_install debería instalarse en /usr/local/lib/python2.6/dist-packages ?
  7. ¿Esto afectará a pip también?

Gracias a cualquiera que pueda aclarar esto!

Estaría tentado a piratearlo haciendo que los paquetes del sitio sean un enlace a dist-packages, pero supongo que esto podría afectar a otros casos en los que desee instalar alguna extensión que no sea de ubuntu dist. No puedo pensar en otra respuesta a 1, excepto en modificar las fonts de virtualenv (con tanto ubuntu como virtualenv son tan populares que no me sorprendería encontrar que ya existían versiones modificadas).

Re 2, si está utilizando / usr / local / bin / python, debe usar la versión / usr / local de la biblioteca (incluidos los paquetes del sitio) y, por el contrario, si está usando / usr / bin / python.

Re 3, habrá algo allí si alguna vez instala una extensión para / usr / bin / python desde fonts (no a través de easy_install o desde la distribución de Ubuntu).

Re 4, sí, las entradas anteriores en la ruta tienen prioridad.

Re 5, easy_install es fácil solo por su nombre: hace tanta magia oscura que se ha mantenido cuidadosamente fuera de la biblioteca estándar de python a pesar de su conveniencia porque el consenso entre nosotros los comensales de python es que la magia oscura profunda para la conveniencia es “fácil” Solo en la superficie.

Re 6, creo que esa es una modificación de ubuntu a easy_install; si es así, entonces se define donde Canonical u otros mantenedores de ubuntu toman sus decisiones colectivas.

Re 7, lo siento, no tengo idea, no tengo un ubuntu razonablemente reciente para verificar.

Creo que la respuesta de Mike Orr de la lista de correo de virtual-env parece ser la mejor. Tenga en cuenta que el OP publicó esta pregunta en ambos lugares.

Contenido original del correo:

Hace años, Debian creó / usr / local / lib / pythonVERSION / site-packages, y compiló el binario de Python para incluirlo en la ruta de búsqueda predeterminada. Ubuntu siguió el ejemplo de Debian como lo hace normalmente. A los desarrolladores de Python no les gustó esto porque obtendrían interferencias con un / usr / local / bin / python instalado localmente usando el mismo directorio site-packages. Ubuntu finalmente decidió abandonar los paquetes de sitio y usar paquetes dist, un nombre que inventaron para que no interfiriera con nada. La historia de loing está disponible en algún lugar si la busca en Google, en algún lugar del rastreador de errores de Python o en los SIG de SIG o similares.

El sistema funciona, al menos si usa el paquete Ubuntu virtualenv. Algunas personas han tenido problemas con el uso de un virtualenv instalado localmente en Ubuntu porque las entradas magic sys.path no se estaban agregando o algo así. No estoy seguro de –no-site-packages porque nunca uso esa opción: ejecuto PIL y mysqldb desde los paquetes de Ubuntu porque a veces puede ser difícil comstackr sus dependencias de C. (Necesita los archivos de encabezado correctos, Python está ignorando los archivos de encabezado, etc.)

Entonces los paquetes de Ubuntu Python van a / usr / lib / pythonVERSION / dist-packages. O ese directorio de soporte de python por alguna razón. Los paquetes de Python instalados localmente van a / usr / local / lib / pythonVERSION / dist-packages por defecto. Cada vez que instalo un sistema Ubuntu 9.04 ejecuto:

$ sudo apt-get install python-setuptools (6.0c9) $ sudo apt-get install python-virtualenv (1.3.3) $ sudo easy_install pip $ sudo pip install virtualenvwrapper

Los virtualesenvs funcionan bien de esta manera, aunque no he probado –no-site-packages.

Estoy tratando de girar virtualenv, y la bandera –no-site-packages parece no hacer nada con ubuntu. Instalé virtualenv 1.3.3 con easy_install (que he actualizado a setuptools 0.6c9)

Estas versiones están en Ubuntu 9.04, por lo que te lo estás haciendo más difícil al instalarlas localmente.

y todo parece estar instalado en /usr/local/lib/python2.6/dist-packages

Supongo que al instalar un paquete utilizando apt-get, se coloca en / usr / lib / python2.6 / dist-packages /?

  1. ¿Primero es el primero en servir en el camino? Si tengo una versión más nueva del paquete XYZ instalado en /usr/local/lib/python2.6/dist- packages / y una versión anterior (de ubuntu repos / apt-get) en / usr / lib / python2.6 / dist -paquetes, ¿cuál se importa cuando importo xyz? Supongo que esto se basa en la lista de rutas, ¿sí?

sys.path se escanea en orden. Lo único gracioso es que los huevos .pth se ponen antes o después en el camino de lo que algunas personas esperan. Pero si está utilizando pip para todo lo que puede hacer (es decir, excepto para instalar pip en sí mismo, huevos precomstackdos y una instantánea de un directorio local que es una copia en lugar de un enlace de egg), no tendrá muchos .pth eggs de todos modos .

  1. ¿Por qué diablos es esto tan confuso? ¿Hay algo que me estoy perdiendo aquí?

No está bien documentado. Lo descubrí escaneando la web.

  1. ¿Esto afectará a pip también?

Sí, pip se instalará automáticamente en / usr / local / lib / pythonVERSION / site-packages. Use “pip install -E $ VIRTUAL_ENV packagename” para instalar en un virtualenv.

Realmente no deberías tocar la instalación de Ubuntu en Python a menos que estés creando herramientas de administración de sistemas o construyas algo que podría considerarse un nuevo servicio de sistema.

Si está utilizando Ubuntu para desarrollar o implementar aplicaciones de Python, siempre compile su propio Python desde la fuente, ajústelo y utilícelo para la implementación. De esa manera, tendrá todos los directorios en el lugar correcto y virtualenv funcionará normalmente. Si implementa varias aplicaciones de Python en el servidor, entonces haga que Python viva en algún lugar como /home/python o /opt/python o en algún lugar fuera de su directorio de inicio. Asegúrese de tener permisos de escritura para el grupo de desarrolladores (¿ users ?) Para que las personas puedan agregar paquetes fácilmente.

Esto también le permite tener dos niveles de paquetes. Las que son sus herramientas estándar internas se pueden instalar en su distro de Python y formar parte del archivo comprimido que implementa, y solo los paquetes específicos de la aplicación estarán en un virtualenv.

No actualices ni modifiques el sistema de Ubuntu instalado en Python.

Bueno, tengo un Ubuntu 9.04 y rápidamente intenté configurar un par de entornos limitados con paquetes de sitios y uno sin ellos. Y las cosas están funcionando bien.

La única diferencia en el enfoque que tomé es que usé el paquete python-virtualenv de Ubuntu (1.3.3). Y suponga que el equipo de Ubuntu lo ha ajustado para que se adapte a las configuraciones de Ubuntu.

Para resumir, deshabilite easy_installed virtualenv por un tiempo, use python-virtualenv empaquetado y vea si cumple con sus expectativas.

De hecho, utilizamos una configuración similar para la producción sin ningún problema. El descanso ya es respondido por Alex.

Otra forma de solucionarlo:
https://stackoverflow.com/a/17265840/202168

Recuerda hacer eso en cada virtualenv donde lo necesites, pero no confíes en hacks o en una versión especial de virtualenv