El vie., 30 sept. 2016 a las 10:53, Antonio Beamud Montero (< antonio.bea...@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>
_______________________________________________ Python-es mailing list Python-es@python.org https://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/