Mejores prácticas para la implementación de Python: varias versiones, ubicaciones de instalación estándar, herramientas de empaquetado, etc.

Question

Muchas publicaciones sobre diferentes aspectos de esta pregunta, pero no he visto una publicación que lo integre todo.

Primera afirmació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 empezamos a lidiar con problemas de implementación. ¿Cuál es la mejor manera de tener múltiples 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 maltratado cuando se trata de despliegue. Estoy sintiendo ecos misteriosos de la experiencia "DLL hell" en Windows.

¿Los expertos están de acuerdo en algún grado de mejores prácticas en estas cuestiones?

¿Te ejecutar varias versiones de Python en el mismo equipo? ¿Cómo se puede confiar en que pueden coexistir? ¿Y la versión más reciente no rompe las suposiciones de otros procesos que se basan en la versión anterior (scripts proporcionados por el proveedor del sistema operativo, por ejemplo)? ¿Esto es seguro? ¿Virtualenv es suficiente?

¿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 Windows OS en las que se puede confiar?

y la esquina más oscuro es del pantano - lo que instalar herramientas utiliza (setuptools, distutils, pip etc.) y qué juegan bien con sus opciones Re: ubicaciones de archivos, entornos virtuales de Python, el recorrido de Python etc.

Suenan preguntas difíciles. Tengo la esperanza de que los Pythonistas experimentados puedan haber definido un enfoque canónico (o dos) para estos desafíos. Cualquier enfoque que "se mantenga unido" como un sistema que se puede usar con confianza (sintiéndose menos como herramientas separadas y no relacionadas) sería muy útil.

Answer 1

Estoy de acuerdo en que esta es una pregunta bastante amplia, pero trataré de abordar sus muchas partes de todos modos.

Sobre su declaración subjetiva: No veo por qué la simplicidad y la elegancia de Python implicarían que los asuntos de empaquetado y despliegue repentinamente deberían convertirse en cosas simples. Algunas cosas relacionadas con el empaque son simples, otras no, otras podrían serlo. Sería mejor para los usuarios si tuviéramos un sistema de empaquetado completo, robusto y fácil, pero no ha cambiado ese camino. Se creó distutils y luego se pausó su desarrollo, se crearon herramientas de configuración y se agregaron nuevas soluciones y nuevos problemas, se distribuyó desde herramientas de configuración debido a problemas sociales, y finalmente se creó distutils2 para hacer una biblioteca completa oficial.(Más sobre Differences between distribute, distutils, setuptools and 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 múltiples versiones de Python en la misma máquina? Use su administrador de paquetes si tiene un sistema operativo moderno, o use "make altinstall" si compila desde el código fuente en UNIX, o use el esquema de instalación similar no conflictivo si compila desde el código fuente en Windows. Como usuario de Debian, sé que puedo llamar a las versiones individuales mediante el uso de "pythonX.Y", y que las versiones predeterminadas ("python" y "python3") son decididas por los desarrolladores de Debian. Algunos sistemas operativos han comenzado a romper la suposición de que python == python2, por lo que hay un PEP en curso para bendecir o condenar eso: http://www.python.org/dev/peps/pep-0394/ Windows parece carecer de una forma de usar una versión de Python como predeterminada, por lo que hay otra PEP: http://www.python.org/dev/peps/pep-0397/

¿Dónde deben instalarse los paquetes? Usando distutils, puedo instalar proyectos en mi directorio de paquetes de sitios de usuario (vea PEP 370 o docs.python.org). Cuál es exactamente la pregunta?

No se admite la instalación paralela de diferentes versiones del mismo proyecto. Necesitaría un PEP para discutir los cambios en el sistema de importación y las herramientas de empaque. Antes de que alguien comience la discusión, usar virtualenv o buildout funciona bastante bien.

No entiendo la pregunta sobre la ubicación de "componentes del entorno de Python".

Principalmente uso paquetes de sistema (es decir, usando el gestor de paquetes Aptitude en Debian). Para probar proyectos, clono su repositorio. Si necesito algo que no está disponible con Aptitude, instalo (o pongo un archivo .pth en el repositorio) en mi directorio de paquetes de sitios de usuario. No necesito una PYTHONPATH personalizada, pero he cambiado la ubicación de mis paquetes de sitio de usuario con PYTHONUSERBASE. No me gusta el concepto de magia y huevos en setuptools/distribute, así que no los uso. Empecé a usar virtualenv y pip para un proyecto (usan setuptools bajo la cubierta, pero hice una instalación privada, así que mi Python global no tiene setuptools).

Answer 2

Un recurso para esta área es el libro Expert Python Programming de Tarek Ziade. Soy ambivalente sobre la calidad del libro, pero los temas tratados son solo en lo que te estás enfocando.

Answer 3

Descubrí que virtualenv es la única manera confiable de configurar y mantener múltiples entornos en la misma máquina. Incluso tiene como forma de empaquetar el entorno e instalarlo en otra máquina.

la gestión de paquetes siempre uso pip ya que funciona tan bien con virtualenv. También facilita la instalación y actualización de paquetes de una variedad de fuentes, tales como repositorios git.