¿Cómo puedo gestionar las dependencias del módulo Perl?

Question

Actualmente estoy en un proyecto que se desarrolla utilizando un marco desarrollado por otro departamento como base. Actualmente estamos introduciendo estándares de calidad (¡por fin, sí!) En nuestro departamento, pero actualmente es imposible presentarlos al otro departamento. Como consecuencia, estamos trabajando contra un objetivo en constante movimiento sin estabilidad de API o versiones estables, lo cual es estresante por lo menos.

Ya que estamos tratando de arreglar las cosas en nuestro extremo primero, nos gustaría asegurarnos lo más posible contra los cambios en el código de marco "upstream" a.k.a. Habíamos previsto dependencias de módulos duros:

1. Uso de ciertos rangos de versión de módulos de infraestructura, definidos en el código.
2. Usando una prueba de unidad de prueba para asegurarse de que todas las versiones necesarias todavía están disponibles.
3. Cada extensión del rango de versión requiere la revisión por pares del código de la estructura.

Ese es el plan hasta ahora. Ahora las preguntas:

1. ¿Es sensato? Si no, ¿alguna otra idea?
2. ¿Cómo se implementa esto en Perl? Utilizando use Module solo podemos definir el código de versión más bajo con el que se supone que debe funcionar.

Answer 1

Aunque espero que CPAN sea más estable que los módulos en los que confía, permítame hacer una pregunta similar: ¿cómo podría protegerse contra cambios inesperados en un módulo de CPAN?

Una respuesta: descargaría el módulo y haría una regresión de su código en un entorno de prueba.

¿Se podría usar lo mismo aquí? ¿Tiene que señalar las copias "en vivo" de sus módulos, o podría señalar sus propias copias?

Answer 2

Me gustaría hacer esto al hacer una copia privada de las bibliotecas de las que depende mi código y ponerlas en el directorio lib de mi proyecto, entendiendo que nunca las modificaré excepto para consultar periódicamente nuevas versiones a medida que se alcancen hitos.

Answer 3

Es un plan muy sensato, y lo implemento a través de un repositorio privado tipo CPAN al que he estado llamando 'DPAN'. Seleccione las distribuciones y versiones que desee del CPAN real (o BackPAN) y cree su propio repositorio a partir de él. Sus clientes de CPAN solo apuntan a este repositorio, congelando de manera efectiva las versiones a exactamente lo que desea. Usted solo actualiza cuando lo desea.

Además, DPAN le permite agregar fácilmente no solo su propio código local y privado, sino también modificar paquetes de terceros para solucionar problemas con sus instalaciones, etc. Tengo una justificación completa para la idea en la edición de verano de 2009 de The Perl Review. También puede ver mis diapositivas de mi conversación Creating Your Own CPAN en YAPC :: Russia.

Si está interesado en este tipo de solución, consulte mi módulo MyCPAN::App::DPAN. Toma un directorio de distros y hace el resto por ti. Dirige a su cliente de CPAN (y se asegura de que no se conecte a Internet) y eso es todo.

Una vez que pueda hacer su propio repositorio, puede hacer fácilmente un repositorio de pruebas.Vuelque las versiones que cree que desea actualizar, despliegue el código en su servidor de prueba y recopile los resultados. Si no le gustan los resultados, puede cambiar fácilmente el repositorio.

El siguiente gran paso en mi trabajo DPAN es tomar una instalación existente de Perl, con los módulos que pueda haber instalado, y crear el repositorio que le daría ese estado de instalación. Tengo todas las piezas principales que necesito para hacer el trabajo, pero he estado un poco ocupado haciendo que un par de clientes corran con los primeros bits.

Si desea saber más acerca de esto, hágamelo saber. :)

Answer 4

Eche un vistazo a PAR. Te permite agrupar un conjunto de dependencias en un archivo. Podrías tomar los módulos que liberan, arrojarlos en un archivo PAR y solo actualizar el archivo PAR cuando quieras aceptar sus cambios.

Answer 5

Si desea comprobar la versión de módulos externos, que podría (si al menos se reportan su $ VERSIÓN correctamente) usar algo como esto:

BEGIN { 
    use foo; 
    use bar; 

    die "Ghaaaa" if $foo::VERSION < 2.1; 
    die "Aaaargh" if $foo::VERSION > 3.12; 
} 

Answer 6

Alguien señaló PAR ya. Permítanme mencionar PAR::Repository y su módulo complementario PAR::Repository::Client. Implementan una infraestructura cliente/servidor que puede cargar automáticamente cualquier dependencia que no se encuentre localmente (o que incluso pueda preferir los paquetes del servidor). Como administrador, puede simplemente agregar o eliminar paquetes hacia o desde su repositorio. El servicio real de los paquetes se realiza con servidores completamente normales: cualquier servidor http (s) o simplemente file: // funcionará. Otros protocolos deberían ser bastante sencillos de implementar.

Cuenta con el mecanismo mágico de carga automática antes mencionado, la instalación del paquete y la actualización automática del paquete. Además de la documentación del módulo, puede echarle un vistazo a presentation on PAR from YAPC::Europe 2008 que cubre esto hasta cierto punto.

Tengo que admitir que la actualización automática es una tecnología suficientemente avanzada que puede comerse a uno o dos bebés si se queda sin gatitos para roer.

Answer 7

Bueno, creo que Carton es algo que está buscando (el paquete para perl). Combinado con plenv creo que hará el truco.