[Python-es] De paquetes y de huevos

Chema Cortes pych3m4 en gmail.com
Vie Sep 30 05:49:51 EDT 2016


El vie., 30 sept. 2016 a las 10:53, Antonio Beamud Montero (<
antonio.beamud en gmail.com>) escribió:

>
> Intento evitar todo eso, mezclar paquetes/librerías instaladas via apt-get
> y las instaladas via pip.
> Imagina que la distribución instala via apt-get un paquete paqX, que
> depende de la librería >=lib1.3. Tu ahora instalas tu egg que depende de la
> librería lib2.9 (que hace cambios en el api de la lib), esa aplicación paqX
> te puede empezar a dar problemas, porque resuelve dependencias contra la
> lib2.9 (incluso peores casos donde no se especifica en los requerimientos
> que versión necesita para funcionar).
> Esto es precisamente lo que intento evitar, y lo que me gustaría es poder
> simular todas las dependencias que tienen una distribución, y poder probar
> paquetes que no están en la distribución para ver que resuelve bien
> dependencias y no genera conflictos.
>
> No hay ningún drama, la idea final es que intento no mezclar paquetes
> instalados con apt-get y con pip, porque al final, lo que quiero es poder
> crear paquetes para las distribuciones que se instalen via apt-get, pero
> antes quiero probar todo en un entorno ligero via virtualenv. (no se si me
> explico).
>
> Para eso necesitaría meter las mismas versiones que llevan las distintas
> distribuciones, y poder crear un virtualenv ubuntu12.04 (por ejemplo),
> instalando ahí con pip las mismas versiones que se instalan via apt-get en
> ubuntu 12.04...
>
>
Si entiendo bien, pretendes mantener versiones distintas según las
distintas distribuciones de linux. Es completamente una locura. Si ya es
complicado mantener versiones para distintas plataformas, ampliar el
espectro a todas las posibles configuraciones es imposible. Por lo menos
tendrás versiones distintas para python2 y python3, además de versiones
diferentes de otras librerías principales (gtk2/gtk3, qt4/qt5,
mysql/mariadb,....).

Este problema es común a todos los lenguajes de programación y la solución
es docker. No sé porqué lo has descartado tan pronto. Si no te parece
liviano coreOS o rancherOS, es que no tenemos el mismo concepto de
"liviano". Hoy en día, incluso se puede asociar la ejecución de un
contendor docker con la carga de un módulo python, similar a lo que sería
la carga de una librería dinámica, pero sin los problemas de dependencias
con librerías del sistema. Por ahí va el futuro de python y de muchos otros
lenguajes, aunque no sabría decirte si será docker, rkt u otro mejor.
-- 
Hyperreals *R  "Quarks, bits y otras criaturas infinitesimales":
http://blog.ch3m4.org <http://ch3m4.org/blog>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://mail.python.org/pipermail/python-es/attachments/20160930/21ad09b1/attachment.html>


Más información sobre la lista de distribución Python-es