¿Cómo puedo manejar las versiones de desarrollo de los paquetes de Python sin depender de SCM?

Question

Un problema que surge durante el desarrollo de Pinax es el manejo de versiones de desarrollo de aplicaciones externas. Estoy tratando de encontrar una solución que no implique traer los sistemas de control de versiones. Por lo que respecta a la razón, preferiría no tener que instalar todos los sistemas de control de versiones posibles en mi sistema (o forzar a los colaboradores) y tratar los problemas que puedan surgir durante la creación del entorno.

Tome esta situación (saber cómo funciona Pinax será beneficioso para la comprensión):

Estamos comenzando el desarrollo de una nueva versión de Pinax. La versión anterior tiene un archivo de requisitos de pip con versiones explícitas establecidas. Se produce un error en una aplicación externa que nos gustaría resolver. Para obtener esa corrección de errores en Pinax, el proceso actual es simplemente hacer una versión menor de la aplicación suponiendo que tenemos el control de la aplicación. Las aplicaciones que no tenemos control solo nos ocupamos del ciclo de lanzamientos del autor de la aplicación o las forzamos a realizar lanzamientos ;-) No soy muy aficionado a realizar constantemente lanzamientos menores para corregir errores, ya que en algunos casos me gustaría ser trabajando en nuevas funciones para aplicaciones también. Por supuesto, la ramificación de la versión anterior es lo que hacemos y luego hacemos backports según lo que necesitamos.

Me encantaría escuchar algunas ideas sobre esto.

Answer 1

Quería mencionar que la solución que había considerado antes de preguntar era poner un PyPI de Pinax y hacer lanzamientos de desarrollo en él. Podríamos poner una instancia de obispo. Ya estamos usando pip's --find-links para apuntar a pypi.pinaxproject.com para paquetes que hemos tenido que liberar.

Answer 2

Podría manejar esto mediante el "== dev" versión especificador? Si la página de distribución en PyPI incluye un enlace a un .tgz de la versión de desarrollo actual (como github y bitbucket proporcionan automáticamente) y anexa "# egg = project_name-dev" al enlace, easy_install y pip usarán eso .tgz si se solicita == dev.

Esto no permite a la clavija a algo más específico que "la punta más reciente/cabeza", pero en muchos casos que podrían ser lo suficientemente bueno?

Answer 3

distribuidores fuente más abiertos (los Debians, Ubuntu'S, MacPorts, et al) utilizan algún tipo de mecanismo de gestión de parches. Así que algo así como: importe el código fuente base para cada paquete como liberado, como una bola de alquitrán o como una instantánea de SCM. A continuación, gestione las modificaciones necesarias encima de él con un administrador de parches, como quilt o Mercurial's Queues. Luego agregue cada paquete externo con los parches aplicados en un formato consistente. O tenga URL a los paquetes base y URL a los parches individuales y solicítelos durante la instalación. Eso es esencialmente lo que hace MacPorts.

EDIT: Para tomar un paso más allá, se podría entonces controlar la versión del conjunto de parches a través de todos los paquetes externos y hacer que disponible como una unidad. Eso es bastante fácil de hacer con Mercurial Queues. Luego, simplificó el problema para simplemente publicar un conjunto de parches usando un sistema SCM, con los parches aplicados localmente como se indicó anteriormente o disponibles para que los desarrolladores los extraigan y apliquen a sus copias de los paquetes de versiones base.

Answer 4

EDIT: No estoy seguro de que estoy leyendo bien su pregunta por lo que el siguiente puede no responder a su pregunta directamente.

algo que he considerado, pero no han probado, está utilizando la función de congelación paquete de PIP. Tal vez usar eso y distribuir el paquete con Pinax funcionaría? Mi única preocupación sería cómo se manejan los diferentes sistemas operativos. Por ejemplo, nunca he usado pip en Windows, así que no sabría cómo interactuaría un paquete allí.

La idea completa espero a tratar es la creación de un guión pavimentadora que controla la gestión de los haces, lo que facilita a los usuarios actualizar a versiones más recientes. Sin embargo, esto requeriría un poco de andamiaje.

Otra opción puede ser que guardes un espejo de las aplicaciones que no controlas, en un vcs consistente y luego distribuyas tus versiones duplicadas. Esto eliminaría la necesidad de que "todos" tengan muchos programas diferentes instalados.

Aparte de eso, parece que la única solución real es lo que ustedes están haciendo, no hay una manera sin problemas que he podido encontrar.