recuperando el bottom-posting...
> > > 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 >> _______ El día 1 de septiembre de 2017, 11:49, Nicolas lino <nicolasli...@gmail.com> escribió: > 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. Vale, no habia entendido bien el contexto. Si, durante la fase de desarrollo, usar RPMs, salvo que lo tengas superautomatizado, no es practico. En mi grupo (para mencionar casos reales), tenemos dos modos de trabajo durante el desarrollo: (1) yo prefiero hacer una primera instalacion como root, para asegurarme de que los ficheros de codigo estan en su sitio, los de configuracion en etc/, los logs se escriben en /var/log, etc. Es decir, siempre empiezo los proyectos por el armazon, con codigo nulo, o que haga lo minimo para confirmar que todo esta en su sitio. Luego escribo codigo en los ficheros instalados, y si todo van bien, hago un rsync a $HOME/src/<project>/ y commit a GITHUB. (2) otros prefieren trabajar directamente en el area $HOME/src/<project>/ (donde se ha hecho git clone, por ejemplo) Para eso basta con tener un bash que prepara el $PYTHONPATH, $PATH, ..., e inicia los procesos apuntando a $HOME/src/<project>/etc, $HOME/src/<project>/log, ... Y si todo va bien, se hace commit directamente. Hay muchas opciones, todo depende de la personalidad de cada uno, y sobre todo del project manager :) Jose P.S. por cierto, perdon por la ausencia de tildes. _______________________________________________ Python-es mailing list Python-es@python.org https://mail.python.org/mailman/listinfo/python-es
