<div dir="ltr"><div class="gmail_quote"><div dir="ltr">El vie., 30 sept. 2016 a las 10:53, Antonio Beamud Montero (<<a href="mailto:antonio.beamud@gmail.com">antonio.beamud@gmail.com</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><div bgcolor="#FFFFFF" text="#000000">
Intento evitar todo eso, mezclar paquetes/librerías instaladas via
apt-get y las instaladas via pip.<br>
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). <br>
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.<br>
<br>
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).<br>
<br>
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...</div><div bgcolor="#FFFFFF" text="#000000"><br></div></blockquote><div><br>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,....).<br><br></div><div>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.<br></div></div></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr"><span>Hyperreals *R "Quarks, bits y otras criaturas infinitesimales": </span><a href="http://ch3m4.org/blog">http://blog.ch3m4.org</a><br></div></div>