2009-11-05 15 views
18

Recientemente leí una publicación de blog diciendo que es una buena práctica desarrollar aplicaciones Perl tal como lo haría con un módulo CPAN. (Here it is - gracias David!) Uno de los motivos es que simplemente puede 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 te encuentras con una aplicación así, sabes lo que hace el archivo MAKE, etc. ¿Cuáles son otras ventajas y desventajas de este enfoque?¿Desarrolla sus aplicaciones Perl como módulos de CPAN?


Actualización: Gracias por las respuestas. Tengo una pregunta más sobre la instalación de la dependencia, voy a post it separately.

Respuesta

11

general, sí, yo diría que es una buena idea. Catalyst hace que esto sea fácil, ya que el script de ayuda 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 .

Editar: Creo que la publicación de blog original en la que estabas pensando era Write your code like it's going on CPAN de Perlbuzz.

" Al tratar el código que nunca lanzaríamos a CPAN como si fuéramos, ganamos el soporte de toda la herramienta de CPAN. Una cadena de herramientas que mejora cada día. "

-4

publicar cosas para CPAN significa responsabilidad. necesita proporcionar un buen documento, más apoyo y otros. o bien, no va CPAN.

Gracias

+7

En realidad, publicar el código en CPAN no era lo que se pedía: "una buena práctica para desarrollar aplicaciones Perl del mismo modo que desarrollarías un módulo CPAN" no implica que realmente la liberes a CPAN, solo que desarrollas en el De la misma manera que lo haría con un módulo que planeaba lanzar a CPAN. –

+4

¿Quiere decir que, si no publica en CPAN, no necesita proporcionar un buen documento ni admitir su código? –

+0

Está amargado de que a alguien en el IRC no le haya gustado su uso del espacio de nombres MooseX ::. – jrockway

6

Sí, simplemente porque "módulo CPAN" solo establece prácticas muy liberales. Prefiero Module :: Install, creo que la gente más sensata también debería. Para obtener una distribución básica funcionamiento con el módulo de instalar simplemente uso del módulo de arranque:

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

A continuación, justo después, puedo editar la vaina en lib/foo/Bar.pm: no me gusta la vaina en el medio de mi código. Normalmente lo muevo todo al fondo y elimino la sección FUNCIÓN, y VERSIÓN también, porque el 99.9% de mis módulos son OO con Moose, y Module :: Install 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 cualquier archivo temporal que sea editor que estoy creando podría estar usando. (Si está presionando para CPAN, querrá agregar el .gitignore, y .git/a MANIFEST.skip de esa manera, ellos no subirán también). Luego I git add ., y tengo mi módulo en git con un sistema de compilación/prueba bootstrapped.

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

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

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

No hay desventajas importantes, o incluso pequeñas notables.

+0

¿Has probado Dist :: Zilla? – brunov

Cuestiones relacionadas