El RPM es super complejo para desarrollar. Por ejemplo, yo podría tener una lib que fuera el ORM de la plataforma, ese ORM lo van a consumir 4 o 5 proyectos, que lo van a utilizar, haciendo un import del modulo.
Al momento de desarrollar, quiero que sea mas dinámico que un RPM, para ir a prod puedo versionar y subir a una registry, para luego tener en el requirements.txt la versión especifica. El 1 de septiembre de 2017, 12:40, Jose Caballero <jcaballero....@gmail.com> escribió: > El día 1 de septiembre de 2017, 11:34, Nicolas lino > <nicolasli...@gmail.com> escribió: > > Buenas. > > > > Estoy encarando un desarrollo extenso, y tengo varias dudas de como > manejar > > múltiples librerías en desarrollo. > > > > Dejo un ejemplo para que se entienda bien. > > > > LibA: en desarrollo, constantes cambios. > > LibB: Desarrollo constantes cambios. > > > > Base: este proyecto tendría que tener from LibA import module1, from LibB > > import module3 > > > > La idea es desarrollar LibA y LibB, y que Base tome los cambios con solo > > reiniciar. > > > > > > Como se maneja esto con python?? > > > > Estuve viendo pip, donde podes importar de un repositorio, pero no me > gusta > > la idea de commitear para ver los cambios. > > > > > > Alguien paso por esto? > > > > > > > Depende mucho del tipo de proyecto, del grupo de desarrolladores, de > la plataforma, etc. > En mi caso, como solo desarrollamos para RedHat, un problema menos: > RPMs y punto. > Normalmente lo que hacemos es distribuir cada libreria con un RPM > separado. Cuando hay un cambio, se instala el nuevo RPM y se > reinicializa todo. > > Por otro lado, todo, absolutamente todo, TODO !! debe estar en un > repo. SVN, GITHUB, ... lo que sea. > > Jose > _______________________________________________ > Python-es mailing list > Python-es@python.org > https://mail.python.org/mailman/listinfo/python-es >
_______________________________________________ Python-es mailing list Python-es@python.org https://mail.python.org/mailman/listinfo/python-es
