Reini Urban's ExtUtils::MakeMaker make release post demonstrates how to add a few of the features of Dist::Zilla to the why-does-this-still-exist ExtUtils::MakeMaker. (Spoiler: it still exists because it's not worth rewriting everything that uses it and continues to work.)
While I think everything about MakeMaker's implementation is blepharitic and, quite likely, contagious, you might find it surprising that I agree in spirit with the point both Reini and educated_foo make in the post and its comments. In summary:
Automating a task is only worthwhile when the benefit of automation outweighs the cost of doing so.
That should be staggeringly obvious to everyone with more than six months of serious programming experience, but it's not.
I spent a few days getting my head around dzil and still haven't updated all of my releasable code to use it because the act of conversion takes a few minutes. If I have no plans to release new versions of that code any time soon, there's little value in performing the conversion. Similarly, if I had a good release strategy in place before dzil came about, the cost of switching would have to be less than the cost of keeping things the same for things to work out. (You can make the same argument about switching between technologies such as languages or editors.)
Sometimes a technology is measurably better. For me, a git-based workflow using dzil beats all of the alternatives I've tried. The same goes for Plack for deployment and cpanminus and perlbrew for managing Perl installations. Yet I happily used Subversion until the pain of managing branches and merges and repositories outweighed the pain of figuring out git.
With that said, Aristotle is right (as usual): automating away all of the
silly little niggly details that are tedious to remember and get right is
almost always worthwhile. Whether that's Reini's EUMM recipe or the dzil
ecosystem depends on who has to automate things. That's the same reason
make test or dzil test or prove -lr t/
is much better than scanning the output of multiple test files and trying to
summarize in your mind.
(Fun fact: in my first few public Perl 5 projects I manually removed all of the CVS directories because I didn't know about CVS export, to say nothing of EUMM. In my defense, this was 1998.)
Sometimes you get lucky and find an automation that lets you share smaller pieces of hard work between lots of other people—there's one advantage of dzil over EUMM. Where a user of EUMM might happily copy Reini's code into every Makefile.PL to add those nice features, a dzil user can install a plugin and use it on every project. (... though I didn't see a NYTProf plugin when I looked yesterday, which surprised me.)
First, what to use if not EUMM if Perl code is fragment of larger project (in C mainly) that uses Makefile?
Second, Dist::Zilla has quite heavy dependencies... though Pod::Weaver looks like fun. Things like automatically testing synopsis etc.
Automating a task is only worthwhile when the benefit of automation outweighs the cost of doing so, OR when publishing that automation to the world will provide benefits for others as well.
When I created Module::Starter, it was partly to save myself the time and hassle of cut & paste module starting, but also to let others avoid it as well.
It's also worth noting that the benefits of automation aren't always based on time. Code quality is a huge benefit, and my understanding of Dist::Zilla is that it takes care of all those little things that we tend to forget on release, eliminating the human error factors.
DRY (Don't Repeat Yourself) is an important principle because it reduces the chances of error. In this respect, it applies to repeated tasks as well.
I think part of the power of Dist::Zilla that is overlooked or underappreciated by novice users is the plugin architecture and particularly user-specific plugin bundles.
For example, after getting about six different "you have a spelling error" bug reports sent back upstream to me from the (awesome) Debian Perl team, I decided that I needed to start spell checking my Pod. I added a spelling plugin [1] (that someone else wrote) to my plugin bundle, tweaked the bundle configuration attributes to let me pass through multiple stop words, and then every single distribution I release has spell checking henceforth.
It's not about whether you can do something with Dist::Zilla versus other tools, it's about whether you want to have Dist::Zilla give you a well-architected way to manage all your distributions similarly with minimal effort (and to customize them when you need to) or whether you want to manage them all separately (or whether you want to roll your own system for doing some or all of what Dist::Zilla does).
The time savings comes not from converting any individual distribution, but from the cumulative compound effect of using Dist::Zilla to automate more and more things and more and more distributions over time.
[1] Dist::Zilla::Plugin::Test::PodSpelling
Exactly. To put another way, good automations compound.
You see this also with the Unix command line.
Dzil's default minting profile uses the @Basic plugin bundle
which includes Dist::Zilla::Plugin::MakeMaker - "Dist::Zilla::Plugin::MakeMaker - build a Makefile.PL that uses ExtUtils::MakeMaker."
You're hating (however mildly) on something that dzil's using behind several layers of abstraction.
I use the Module::Build plugin, and even if I didn't, I don't have to work with MakeMaker directly, but point well taken.