@@ -38,4 +38,21 @@ This could be the end of the story were it not for CPAN. A package needs more t
''Module::Starter'' does in now way obsolete ''Module::Build'' but rather gives you a head start to use it properly for CPAN conforming Perl packages.
===== Dist::Zilla =====
\ No newline at end of file
===== Dist::Zilla =====
While ''module-starter'' gives you a nice skeleton for your package you still need to maintain consistency and update all the boilerplate over the lifetime of your package. This is where ''[[http://dzil.org/|Dist::Zilla]]'' shines. It collects all the relevant information in a file called ''dist.ini'' and puts the documentation close to where it belongs (e.g., as POD text inside Perl code or in designated .pod files). The goal is to avoid redundancies whenever possible and it is impressive how far that can go. If you need to update a piece of information (e.g., a version number) you edit it in exactly one place and the rest is generated by ''Dist::Zilla''.
The typical workflow for, say, an internally used module ''Foo::Bar'' at version 1.4 becomes like this:
dzil build
cd Foo-Bar-1.4
perl Build.PL
./Build
./Build test
./Build install
Or if you want to submit to CPAN you will use the ''.tar.gz'' file generated by ''dzil build'' directly or even use ''dzil'' to upload to CPAN automatically.
All of the files ''dzil'' generates are put in a target directory and none of your source files are changed by ''dzil''. This allows you to keep generated files strictly separate from the files you edit. It also enables consistent builds. ''dzil build'' will allways generate all boilerplate and keep the distribution of your package consistent.
''Dist::Zilla'' supports both ''Module::Build'' and ''ExtUtils::MakeMaker'' as backends. So you continue to profit from the work that went into ''Module::Build'' and avoid the burden of updating all the boilerplate.
