In other news, while CPAN frantically installs about a million packages, I’ve finally made a breakthrough in understanding what Dist::Zilla is for.

While ExtUtils::MakeMaker and Module::Build and friends are for actually installing a distribution from CPAN or similar (and thus contain all the magic to either generate a makefile to do it, or do the magic themselves), instead, Dist::Zilla is for actually building the distributions.

Unclear? Me too.

Putting together a CPAN-ready distribution is a lot of work for a busy programmer. Maintaining a Makefile.PL or Build.PL is apparently not an easy thing to be doing all the time — nor is managing version numbers everywhere, the various documents that ship with everything (to wit, README, LICENSE, INSTALL, MANIFEST, META.yml, Changes and friends) that are all purely administrative but are all required in some way or other.

Dist::Zilla removes the task of having to do all these things. It’s not intended to be used by the user who’s installing modules because they’re dependencies, but instead by the person who’s actually putting the damn’ thing together.

While, initially, I was skeptical (and Dist::Zilla’s dist.ini file appears even more terse and cryptic than an equivalent Makefile.PL or Build.PL), in the long run there’s less to be written, and it optimises out huge bits of what would ordinarily be just heavy-lifting in the workflow. For instance, instead of manually having to, in Git, tag, branch and/or push a repository containing a module, the Git plugin bundle does it for you.

Compare, without Dist::Zilla’s Git plugin:

> sed -i.bak -e "s/0.39/0.40/g" Makefile.PL lib/Awesome/Module.pm
> (echo "v0.40 released."; cat Changes) > Changes.tmp
> mv Changes.tmp Changes
> git commit Makefile.PL lib/Awesome/Module.pm Changes
> git tag v0.40
> git push --all origin
> git push --tags origin

to (assuming you’ve set up everything correctly):

> sed -i.bak -e "s/0.39/0.40/g" lib/Awesome/Module.pm
> git commit lib/Awesome/Module.pm
> V=0.40 dzil release

which is, in my opinion, a bit of a saving. That assumes, of course, you’ve done the work to configure automatic change-log generation, automatic version numbering, Git tagging and pushing to a repository as well as pushing release distributions to CPAN.

There are other things, of course: TravisCI integration, automated testing using perlbrew, perltidy runs, as well as integration into Subversion, Mercurial, Twitter… the list goes on.

But I can see how it’s useful. And I plan to use it in future.