2010-08-04 7 views
10

Empecé a usar Dist::Zilla hace varios meses. Sin embargo, en YAPC :: NA alguien mencionó que usan ShipIt en su lugar. Entonces hoy noté un archivo .shipit en miyagawa cpanminus directory on github, así que decidí investigarlo un poco más ...¿Cuáles son las fortalezas/debilidades de ShipIt vs Dist :: Zilla?

Mi impresión inicial es que ShipIt tiene un subconjunto de lo que está disponible con Dist :: Zilla, pero yo no No quiero sacar conclusiones precipitadas. Entonces, para aquellos que han tenido experiencia con ambos, ¿cuáles son las fortalezas/debilidades de ShipIt vs Dist::Zilla?

crossposted at perlmonks

+0

posible duplicado de [¿Qué marco debo usar para escribir módulos?] (Http://stackoverflow.com/questions/73889/which-framework-should-i-use-to-write-modules); ver también [¿Cuál es el mejor sistema para instalar una aplicación web Perl?] (http://stackoverflow.com/questions/143680/whats-the-best-system-for-installing-a-perl-web-app), y [¿Debo usar Module :: Install o Module :: Build?] (Http://stackoverflow.com/questions/369209/should-i-use-moduleinstall-or-modulebuild) – Ether

+3

No votando para cerrar porque ninguno de esos enlaces (o SO en general) parecen cubrir ShipIt –

+2

@Eric: si la pregunta es la misma, entonces las respuestas deben actualizarse para incluir ShipIt. No sé nada al respecto, por lo que agradecería una comparación con otros conocidos motores de envasado. – Ether

Respuesta

7

Soy el autor de Dist :: Zilla.

Evalué ShipIt bastante extensivamente antes de elegir continuar y escribir Dist :: Zilla, y en un principio cubrieron casi exactamente el mismo espacio problemático: haciendo todo el trabajo aburrido de construir y cargar una distribución de CPAN. Todas las características que Dist :: Zilla tiene ahora más allá de ShipIt son adiciones posteriores, más o menos.

Si solo necesita las funciones de ShipIt, I todavía le aconsejo que considere fuertemente Dist :: Zilla, por una razón muy simple: la piratería. Si hubiera podido escribir algo nuevo, habría usado ShipIt, pero me pareció poco documentado y difícil de extender. Sus complementos no eran lo suficientemente genéricos y el comportamiento del núcleo hizo demasiadas suposiciones sobre cómo le gustaría trabajar.

Dist :: Zilla se inspiró específicamente en este problema: convirtió todo en un complemento, y cada complemento recibió una interfaz muy, muy pequeña para que sus suposiciones se vieran limitadas por la fuerza.

Uno de los beneficios de ShipIt over Dist :: Zilla es que ShipIt tiene (hasta donde tengo conocimiento) sin complementos que alterarán la forma en que realmente escribe su código.Esto significa que su documentación seguirá igual, todavía tendrá un Makefile.PL, y así sucesivamente. A algunos hackers no les gusta que tantos disquetes basados ​​en DZ cambien fundamentalmente las suposiciones de cómo probar y compilar el código CPAN desde su repositorio de origen. ShipIt nunca cambiará eso.

Es posible evitar el uso de tales complementos con Dist :: Zilla, pero en general mi experiencia es que las personas hacen los usan, casi siempre, de una forma u otra.

4

Por lo que yo puedo decir, mis impresiones iniciales eran correctas.

ShipIt proporciona funcionalidad para liberación distribuciones: pista

  • mantenimiento de los números de versión
  • la integración con el control de versiones
  • subir a CPAN
  • que exhiben el fichero de cambios en una editor para que pueda editarlo antes del lanzamiento.


Dist :: Zilla, por defecto, ofrece la posibilidad de cargar las distribuciones a CPAN con un único comando (es decir dzil release). Dist :: Zilla también tiene funcionalidad para creando nuevas distribuciones (es decir, dzil new My::New::Module). También genera automáticamente tantos archivos que solía tener para mantenerlos a mano.

Usando complementos, Dist :: Zilla parece capaz de proporcionar la mayoría, si no la totalidad, de la funcionalidad disponible con ShipIt. También es relativamente fácil agregar nuevas características usando complementos.

Cuestiones relacionadas