Las mejores prácticas para la implementación de Python: varias versiones, ubicaciones de instalación estándar, herramientas de empaquetado, etc.
virtualenv distutils (3)
Muchas publicaciones sobre diferentes aspectos de esta pregunta, pero no he visto una publicación que lo agrupe todo.
Primero, una declaración subjetiva: parece que la simplicidad que experimentamos cuando trabajamos con el lenguaje Python se hace pedazos cuando nos movemos fuera del intérprete y comenzamos a lidiar con los problemas de implementación. ¿Cuál es la mejor manera de tener varias versiones de Python en la misma máquina? ¿Dónde se deben instalar los paquetes? Disutils vs. setuptools vs. pip, etc. Parece que el Zen de Python está siendo abusado bastante mal cuando se trata de la implementación. Estoy sintiendo ecos misteriosos de la experiencia "DLL hell" en Windows.
¿Están de acuerdo los expertos en algún grado de buenas prácticas en estas preguntas?
¿Ejecutas múltiples versiones de Python en la misma máquina? ¿Cómo confía en que puedan coexistir, y la versión más reciente no rompe las suposiciones de otros procesos que se basan en la versión anterior (secuencias de comandos proporcionadas por el proveedor del sistema operativo, por ejemplo)? ¿Es esto seguro? ¿Basta virtualenv?
¿Cuáles son las mejores opciones para las ubicaciones de los diferentes componentes del entorno de Python (incluidos los paquetes de terceros) en el sistema de archivos local? ¿Existe una correspondencia estricta o aproximada entre ubicaciones para muchas versiones diferentes de Unixy y sistemas operativos de Windows en las que se puede confiar?
Y el rincón más oscuro del pantano: qué herramientas de instalación utiliza (herramientas de configuración, herramientas, etc.) y se reproducen bien con sus elecciones: ubicaciones de archivos, entornos virtuales de Python, ruta de Python, etc.
Estas suenan como preguntas difíciles. Espero que los pitonistas experimentados hayan definido un enfoque canónico (o dos) para estos desafíos. Cualquier enfoque que se "junte" como un sistema que se pueda usar con confianza (sintiéndose menos como herramientas separadas y no relacionadas) sería muy útil.
Descubrí que virtualenv es la única forma confiable de configurar y mantener múltiples entornos en la misma máquina. Incluso tiene como una forma de empaquetar el entorno e instalarlo en otra máquina.
Para la gestión de paquetes siempre uso pip ya que funciona muy bien con virtualenv . También facilita la instalación y actualización de paquetes desde una variedad de fuentes, tales como repositorios git.
Estoy de acuerdo en que esta es una pregunta bastante amplia, pero intentaré abordar sus muchas partes de todos modos.
Acerca de su declaración subjetiva: no veo por qué la simplicidad y la elegancia de Python implicarían que los aspectos de empaquetado y despliegue de repente deberían convertirse en cosas simples. Algunas cosas relacionadas con el embalaje son simples, otras no, otras podrían ser. Sería mejor para los usuarios si tuviéramos un sistema de empaquetado completo, robusto y fácil, pero no ha funcionado de esa manera. se creó distutils y luego se detuvo su desarrollo, se crearon setuptools y se agregaron nuevas soluciones y nuevos problemas, se distribuyeron bifurcaciones de setuptools debido a problemas sociales, y finalmente se creó distutils2 para crear una biblioteca oficial completa. (Más sobre Diferencias entre distribución, distutils, setuptools y distutils2? ) La situación dista mucho de ser ideal para desarrolladores y usuarios, pero estamos trabajando para mejorarla.
¿Cuál es la mejor manera de tener varias versiones de Python en la misma máquina? Use su administrador de paquetes si está en un sistema operativo moderno, o use "make altinstall" si compila desde la fuente en UNIX, o use el esquema de instalación similar no conflictivo si compila desde la fuente en Windows. Como usuario de Debian, sé que puedo llamar a las versiones individuales utilizando "pythonX.Y", y que los desarrolladores de Debian deciden cuáles son las versiones predeterminadas ("python" y "python3"). Algunos sistemas operativos han comenzado a romper el supuesto de que python == python2, por lo que hay un PEP en curso para bendecir o condenar que: http://www.python.org/dev/peps/pep-0394/ Windows parece carecer una forma de usar una versión de Python como predeterminada, así que hay otra PEP: http://www.python.org/dev/peps/pep-0397/
¿Dónde se deben instalar los paquetes? Usando distutils, puedo instalar proyectos en mi directorio de paquetes de sitios de usuarios (ver PEP 370 o docs.python.org). Cuál es exactamente la pregunta?
No se admite la instalación en paralelo de diferentes versiones del mismo proyecto. Necesitaría un PEP para discutir los cambios en el sistema de importación y las herramientas de empaquetado. Antes de que alguien comience la discusión, usar virtualenv o buildout funciona lo suficientemente bien.
No entiendo la pregunta sobre la ubicación de "componentes del entorno Python".
Principalmente utilizo paquetes de sistema (es decir, uso el administrador de paquetes de Aptitude en Debian). Para probar proyectos, clono su repositorio. Si necesito algo que no esté disponible con Aptitude, instalo (o coloco un archivo .pth en el repositorio) en mi directorio de paquetes de sitios de usuarios. No necesito un PYTHONPATH personalizado, pero he cambiado la ubicación de mis paquetes de sitio de usuario con PYTHONUSERBASE. No me gusta la magia y el concepto de los huevos en setuptools / distrib, por lo que no los uso. Sin embargo, empecé a usar virtualenv y pip para un proyecto (ellos usan setuptools debajo de la cubierta, pero hice una instalación privada por lo que mi Python global no tiene setuptools).
Un recurso para esta área es el libro Expert Python Programming de Tarek Ziade. Soy ambivalente con respecto a la calidad del libro, pero los temas que se tratan son exactamente en lo que te estás enfocando.