perl - mcpan - ¿Qué marco debería usar para escribir módulos?

perl mcpan

Question

¿Cuál es el mejor marco para escribir módulos? ExtUtils::MakeMaker (h2xs) o Module::Build ?

Answer 1

Acabo de subir Distribution::Cooker a CPAN. Es lo que uso para hacer nuevas distribuciones. Lo bueno de esto es que tus distribuciones pueden ser lo que quieras: solo estás cocinando algunas plantillas. No me importa si alguien lo usa. Para mí es simple, de baja tecnología y no causa problemas adicionales.

Puede comenzar con algo como Module::Starter para crear sus plantillas de inicio y luego agregar su propio texto repetitivo y su forma favorita de hacer las cosas. Usted elige no solo lo que desea en cada archivo, sino también los archivos que aparecen en la distribución. A medida que descubra cómo le gusta hacer las cosas, simplemente actualice sus propias plantillas.

En cuanto a Makemaker y Module :: Build, el futuro es Module :: Build . Solo somos nosotros los viejos usando Makemaker. :) Hay formas de usar ambos (o pretender usar ambos) al mismo tiempo. Consulte Module :: Build, Module :: Build :: Compat y Module :: Install docs . Module :: Build fue expulsado de la biblioteca estándar de Perl y su futuro es incierto. Está de vuelta a Makemaker como un sistema de compilación.

Aunque se trata de una respuesta de escape, intente utilizar cada uno para obtener una pequeña experiencia con cada uno.

Answer 2

Aquí hay una pequeña aclaración de la dirección que esperaba que tomarían las respuestas:

• pros / contras de varios de marcos
• compatibilidad / instalación base de marcos
• idoneidad para versiones internas (locales) frente a externas (CPAN)
• respuestas no desnudas de "use X"

La respuesta de Dave tiene buena información pro / con. La respuesta de Leon alude a la compatibilidad, pero no es explícita. Como mencionó Brian Foy , solo los sombreros antiguos usan EUMM, pero no estoy convencido de que MB sea un buen marco para cosas destinadas a CPAN debido a que no forma parte del núcleo hasta 5.9.

Answer 3

EU :: MM todavía parece ser el más popular y el más apoyado, pero Module :: Build se está poniendo al día. Además, consulte Module::Starter para obtener un módulo que lo ayudará a comenzar.

Answer 4

El único problema con la compatibilidad con Module :: Build es cuando un usuario intenta instalar módulos sin actualizar su cliente CPAN (CPAN.pm o CPANPLUS.pm). Si están instalando su módulo desde el CPAN, pueden actualizar su cliente con la misma facilidad. desde el mismo espejo.

Si no quiere hacer nada complicado en su proceso de compilación, seguro: use EUMM. Pero si tiene un problema de compilación en una plataforma de destino diferente, puede terminar en el archivo Makefile, que es diferente en cada variación de marca.

Module :: Build le ofrece muchas características (cualquier cosa que pueda pensar si lo extiende) y todo es perl, por lo que nunca termina depurando un archivo MAKE. Module :: Install le ofrece características, pero debe agruparlas y todo termina ejecutando ''make'' al final.

Answer 5

Hay dos preguntas aquí.

Primero, nunca uses h2xs. Es viejo y desagradable, aunque supongo que si realmente estás tratando de convertir un archivo de cabecera en código XS, podría ser útil (nunca lo hice yo).

Actualización de 2011: Recomiendo echar un vistazo a Dist :: Zilla , especialmente si crees que mantendrás más de un módulo.

Para crear un nuevo módulo, use Module :: Starter. Funciona muy bien, y tiene algunos buenos complementos para personalizar la salida.

En segundo lugar, estás preguntando qué sistema de compilación debes usar. Los tres contendientes son ExtUtils :: MakeMaker (EUMM), Module :: Build (MB) y Module :: Install (MI).

EUMM es un horrible trabajo desagradable, pero funciona, y si no estás personalizando tu proceso de compilación, funciona bien.

MB es el chico nuevo, y tiene sus detractores. La gran ventaja es que si desea personalizar en gran medida su instalación y proceso de compilación, es muy posible hacerlo de forma sana (y de forma multiplataforma) con MB. Realmente no es posible usar EUMM.

Finalmente, MI es básicamente un contenedor declarativo sobre EUMM. También se empaqueta junto con su distribución, en un intento de solucionar los problemas con los usuarios que intentan instalar módulos con módulos antiguos de la cadena de herramientas. La desventaja del truco del "auto paquete" es que si hay un error en MI en sí mismo, tienes que volver a lanzar todos tus módulos solo para solucionarlo.

En cuanto a la personalización, existen algunos complementos para MI, pero si quieres ir más allá de ellos, estarás de vuelta en el problema de lidiar con Makefiles y herramientas de compilación en más de una docena de plataformas, por lo que realmente no va a ayudar demasiado en ese reino.

Answer 6

Hay ventajas y desventajas para ambos. Estos días uso y recomiendo Module :: Build y Module :: Starter.

Answer 7

Module :: Build es mejor de todos modos, pero tiene menos soporte que ExtUtils :: MakeMaker (más específicamente, las versiones anteriores de Perl no lo admiten de fábrica). Depende de tus necesidades.

Answer 8

Personalmente, recomiendo Module :: Install, al igual que mucha gente que conozco, gente como Catalyst y Moose también lo usan.

Answer 9

También es posible que desee ver Dist-Zilla que es una nueva herramienta de solo autor para crear distribuciones. Debido a que solo ayuda a construir la distribución, no se envía con su código ni realiza ninguna instalación, puede hacer muchas cosas poderosas.

Answer 10

También recomiendo Module :: Build y Module :: Starter (con el plugin TT2 ).

Answer 11

NOTA: este consejo no está actualizado. Module :: Build ha sido eliminado del núcleo de Perl, pero sigue vivo como un módulo de CPAN. Los pros y los contras siguen en pie, y mis opiniones sobre MakeMaker siguen en pie.

Como ex mantenedor de ExtUtils :: MakeMaker, me gusta recomendar Module :: Build porque MakeMaker es un espectáculo de terror. Module :: Build está mucho mejor armado. Pero esas no son sus inquietudes y le presentaré mi respuesta de "menos molestias".

Resumen ejecutivo:

Como el soporte de Module :: Build no está 100% en su lugar a través de Perl, comience con MakeMaker. Si quiere hacer alguna personalización, cambie a Module :: Build. Dado que su diseño básico, opciones e interfaz son casi idénticos, esto será sencillo. Tan seductor como parece, evite Module :: Install.

Afortunadamente, Module :: Build puede emular MakeMaker, lo que ayuda a algunos, pero no ayuda si va a hacer cualquier personalización. Ver Module::Build::Compat .

Para las versiones de CPAN que usan Module :: Build está bien. Ya hay suficiente material de Module :: Build en CPAN que todos ya se han ocupado de ponerlo en marcha.

Finalmente, la nueva opción configure_requires permite a los shells de CPAN saber instalar Module :: Build antes de que puedan comenzar a construir el módulo. Lamentablemente, solo los últimos shells de CPAN conocen sobre configure_requires.

Oh, lo que sea que hagas, no uses h2xs (a menos que estés escribiendo código XS ... e incluso entonces piensa en ello).

MakeMaker Pros:

• Viene con Perl y es utilizado por el núcleo de Perl (por lo tanto, se mantiene activamente y lo seguirá siendo para siempre)
• Todo sabe qué hacer con un Makefile.PL.
• La mayoría de la documentación de autoría del módulo cubrirá MakeMaker.
• Usos make (los que saben pueden depurar y parchear el proceso de compilación)

MakeMaker Contras:

• Requiere make (piense en Windows)
• Difícil de personalizar
• Aún más difícil de personalizar y hacer plataforma cruzada
• Difícil de depurar cuando algo sale mal (a menos que entiendas hacer)

Módulo :: Desarrollar Pros:

• Más fácil de personalizar / subclase
• Pure Perl
• Más fácil de depurar (es Perl)
• Puede emular MakeMaker de varias maneras
• El shell CPAN instalará Module :: Build para usted

Module :: Build Cons:

• Los desarrolladores de Module :: Build (y de hecho todos los Perl Toolchain Gang) lo odian
• Las versiones anteriores de los clientes de CPAN (incluido CPANPLUS) no saben nada sobre Module :: Build.

Módulo :: Instalar Pros:

• Interfaz elegante
• Bundles en sí, tienes una versión conocida
• Todo sabe cómo lidiar con un Makefile.PL

Module :: Install Cons:

• Requiere hacer
• Siempre usa una versión empaquetada, vulnerable a la rotura externa
• Difícil de personalizar fuera de su interfaz
• Atasca con las agallas de MakeMaker para que una nueva versión de MakeMaker eventualmente la rompa.
• No sabe cómo generar un archivo META utilizando la meta-especificación v2 (cada vez más un problema con las herramientas más nuevas)