Cómo mantener proyectos de python duraderos w.r.t. dependencias y versiones de Python?

Question

versión corta: ¿cómo puedo deshacerme de la pesadilla de versiones múltiples de Python?

versión larga: en los últimos años, he utilizado varias versiones de pitón, y lo que es peor, varias extensiones al pitón (por ejemplo pygame, pylab, wxPython ...). Cada vez que estaba en una configuración diferente, con diferentes sistemas operativos, a veces diferentes arquitecturas (como mi viejo Mac PowerPC).

Hoy en día estoy usando un mac (OSX 10.6 en x86-64) y es una pesadilla de dependencia cada vez que quiero revivir el script anterior a unos pocos meses. Python en sí ya viene en tres sabores diferentes en /usr/bin (2.5, 2.6, 3.1), pero tuve que instalar 2.4 de macports para pygame, algo más (no recuerdo qué) me obligó a instalar los otros tres de macports también, así que a al final del día, soy el feliz propietario de siete (!) instancias de python en mi sistema.

Pero ese no es el problema, el problema es que ninguno de ellos tiene las bibliotecas correctas (es decir, el mismo conjunto) instaladas, algunas de ellas son de 32 bits, algunas de 64 bits, y ahora estoy prácticamente perdido.

Por ejemplo, ahora estoy tratando de ejecutar un script de tres años (no escrito por mí) que solía usar matplotlib/numpy para dibujar un gráfico en tiempo real dentro de un rectángulo de una ventana de wxwidgets. Pero estoy fallando miserablemente: py26-wxpython de macports no se instalará, stock python tiene wxwidgets incluidos pero también tiene algún conflicto entre 32 bits y 64 bits, y no tiene numpy ... ¡qué desastre!

Obviamente, estoy haciendo las cosas mal. ¿Cómo usted usualmente enfrentamos todo ese caos?

Answer 1

Algunos consejos:

• en Mac OS X, utilice solamente la instalación de pitón en /Library/Frameworks/Python.framework.
• siempre que use numpy/scipy/matplotlib, instale la distribución python enthought
• use virtualenv y virtualenvwrapper para mantener las instalaciones "del sistema" intactas; idealmente use un entorno virtual por proyecto, para que se cumplan las dependencias de cada proyecto. Y, sí, eso significa que potencialmente se duplicará mucho código en los diversos entornos virtuales.

Eso parece mucho más complicado, pero al menos las cosas funcionan de esa manera. Básicamente, si uno de los proyectos funciona en virtualenv, seguirá funcionando independientemente de las actualizaciones que realice, ya que nunca cambia las instalaciones del "sistema".

Answer 2

Eche un vistazo a virtualenv.

Answer 3

Lo que suelo hacer es intentar (progresivamente) mantenerse al día con las versiones de Python a medida que aparecen (y una vez que todas las dependencias externas tienen las versiones correctas disponibles).

La mayoría de las veces el código de Python se puede transferir tal como está, con solo modificaciones menores necesarias.

Mi mayor proyecto Python @ work (15.000+ LOC) es ahora en Python 2.6 algunos meses (mejora de todo, desde Python 2.5 hizo tomar más de un día debido a la instalación/comprobación 10+ dependencias ...)

En general creo que esta es la mejor estrategia con la mayoría de los componentes interdependientes en la pila de software libre (piensen en las dependencias de los repositorios de software de Linux): mantengan sus versiones (semi) -actuales (o al menos: progresen al mismo ritmo)

Answer 4

Resuelvo esto usando virtualenv. Simpatizo con querer evitar capas adicionales de abstracción de pesadilla, pero virtualenv es increíblemente limpio y fácil de usar. Usted, literalmente, hace esto (línea de comandos, Linux):

virtualenv my_env 

Esto crea un nuevo binario pitón y la ubicación de la biblioteca, y los enlaces simbólicos a sus bibliotecas existentes del sistema por defecto. Luego, para cambiar las rutas para usar el nuevo entorno, haga esto:

source my_env/bin/activate 

Eso es todo. Ahora, si instala módulos (por ejemplo, con easy_install), se instalarán en el directorio lib del directorio my_env.No interfieren con las bibliotecas existentes, no tienes conflictos extraños, las cosas no dejan de funcionar en tu antiguo entorno. Están completamente aislados.

Para salir del entorno, acaba de hacer

deactivate 

Si decide que ha cometido un error con una instalación, o que no quieren que el medio ambiente más, simplemente eliminar el directorio:

rm -rf my_env 

Y listo. Es realmente así de simple.

virtualenv es genial. ;)

Answer 5

Utilizo la versión de MacPorts para todo, pero como puede observar, muchas de las versiones predeterminadas son extrañamente antiguas. Por ejemplo, vim omnicomplete en Snow Leopard tiene python25 como dependencia. Muchos puertos relacionados con Python tienen dependencias antiguas, pero generalmente se puede marcar la versión más nueva en tiempo de compilación, por ejemplo port install vim +python26 en lugar de port install vim +python. Haga un recorrido en seco antes de instalar cualquier cosa para ver si está tirando, por ejemplo, de la totalidad de python24 cuando no es necesario. Compruebe portfiles a menudo porque la convención de nomenclatura como puertos Darwin estaba despegando dejaba algo que desear. En la práctica, dejo todo en las carpetas predeterminadas /opt... de MacPorts, incluida una copia del marco completo con duplicados de PyObjC, etc., y simplemente me quedo con una versión a la vez, conservando la opción de volver al sistema predeterminado si las cosas romper inesperadamente. Lo cual es quizás demasiado trabajo para evitar el uso de virtualenv, que he querido utilizar.

Answer 6

He tenido buena suerte con Buildout. Configura una lista de los huevos y las versiones que desea. Buildout luego descarga e instala versiones privadas de cada uno para usted. Hace un binario privado "python" con todos los huevos ya instalados. Un "nosetest" local hace que las cosas sean fáciles de depurar. Puedes extender la construcción con tus propias funciones.

En el lado negativo, Buildout puede ser bastante misterioso. Haga "buildout -vvvv" por un tiempo para ver exactamente qué está haciendo y por qué.

http://www.buildout.org/docs/tutorial.html

Answer 7

• instalar las versiones de Python que necesita, mejor si a partir de fuentes
• cuando se escribe un guión, incluyen la versión de Python completo en él (como #!/usr/local/bin/python2.6)

I no puedo ver lo que podría salir mal

Si algo falla, es probable que sea una falla macports, no tuya (una de las razones por las que ya no utilizo macports).

Sé que probablemente me falta algo y esto hará que downvoted, pero por favor, deje al menos un pequeño comentario en ese caso, gracias :)

Answer 8

Al menos en Linux, múltiples pitones pueden coexistir bastante feliz Uso Python 2.6 en un sistema CentOS que necesita Python 2.4 para ser el predeterminado para varias cosas del sistema. Simplemente compilé e instalé Python 2.6 en un árbol de directorio separado (y agregué el directorio bin apropiado a mi ruta) que fue bastante sencillo. Luego se invoca escribiendo "python2.6".

Una vez que tenga las pitones separadas en funcionamiento, la instalación de bibliotecas para una versión específica es sencilla. Si invoca el script setup.py con el python que desea, se instalará en directorios apropiados para ese python, y los scripts se instalarán en el mismo directorio que el ejecutable de python y automáticamente usarán el python correcto cuando se invoque.

También trato de evitar el uso de demasiadas bibliotecas. Cuando solo necesito una o dos funciones de una biblioteca (por ejemplo, scipy), a menudo veo si puedo copiarlas a mi propio proyecto.