perl deployment maintenance

¿Desarrolla sus aplicaciones Perl como módulos CPAN?



deployment maintenance (3)

En general, sí, yo diría que es una buena idea. Catalyst hace fácil, ya que el script helper catalyst.pl configurará un marco básico para su aplicación web, completado con un Makefile.PL, etc.

Esto significa que empaquetar su aplicación y desplegarla en un servidor es trivialmente fácil.

Edit: Creo que la publicación original del blog en la que estabas pensando era Escribe tu código como si fuera el CPAN de Perlbuzz .

"Al tratar el código que nunca íbamos a lanzar al CPAN como si lo fuéramos, ganamos el soporte de toda la cadena de herramientas del CPAN. Una cadena de herramientas que está mejorando cada día".

Recientemente leí una entrada de blog que dice que es una buena práctica desarrollar aplicaciones de Perl tal como lo haría para desarrollar un módulo CPAN. (¡ Aquí está , gracias David!) Una de las razones que se dieron fue que simplemente podía ejecutar cpan . en el directorio del proyecto para instalar todas las dependencias. Esto suena razonable, y también me gusta la "interfaz uniforme" que obtienes. Cuando se encuentra con una aplicación de este tipo, sabe lo que hace el makefile, etc. ¿Cuáles son otras ventajas y desventajas de este enfoque?

Actualización: Gracias por las respuestas. Tengo una pregunta más sobre la instalación de dependencias, la publicaré por separado .


Publicar cosas para CPAN significa responsabilidad. Necesita proporcionar un buen documento, apoyo adicional y otros. O bien, no vayas CPAN.

Gracias


Sí, simplemente porque el "módulo CPAN" solo establece prácticas muy liberales. Prefiero el Módulo :: Instalar, creo que la mayoría de las personas sanas deberían hacerlo también. Para obtener una distribución básica que se ejecuta con la instalación del módulo, simplemente uso el inicio del módulo:

module-starter --mi --module "Foo::Bar" --author "Evan Carroll" --email "[email protected]"

Luego, justo después, edito el pod en lib / Foo / Bar.pm: no me gusta pod en el medio de mi código. Por lo general, lo muevo todo al final y también elimino la sección FUNCIÓN y VERSIÓN, porque el 99.9% de mis módulos son OO con Moose, y el Módulo :: Instalar lo leerá desde $ Foo :: Bar :: VERSIÓN.

Luego ejecuto git-init, edito el archivo .gitignore y agrego ''MANIFEST'', ''Meta.yml'', ''Makefile.old'', ''blib /'', ''inc /'', y todos los archivos temporales que el editor estoy La creación podría estar utilizando. (Si está presionando hacia CPAN, querrá agregar .gitignore, y .git / a MANIFEST.skip de esa manera, no subirán demasiado). Luego, git add . , y tengo mi módulo en git con un sistema de prueba / compilación bootstrapped.

Luego ejecuto github, creo un repositorio, subo mi módulo y agrego el repositorio público al repositorio Makefile.PL repository git://github.... y comienzo la codificación.

Incluso si no presiona CPAN, module-install proporciona una base bastante buena para un buen módulo.

Otras ventajas, puede ejecutar make dist , obtener un archivo comprimido y hospedarlo muy fácilmente en un servidor http privado, y luego simplemente decirle a un cliente o servidor que lo instale con cpanp http://host/path . También obtiene todas las ventajas de Module::Install , usará dmake en Windows y descargará dmake si no lo tiene. Es bastante mágico con bondad multiplataforma.

No hay mayores desventajas, ni siquiera las más importantes.