At the Pittsburgh Perl Workshop this year, I gave a lightning talk about
Dist::Zilla, the
system I am increasingly using to manage my CPAN distributions. I'm using it
instead of writing a Makefile.PL, but it doesn't do the same thing as
Module::Build or ExtUtils::MakeMaker. I'm using it instead of running
module-starter, but it doesn't do the same things as Module::Starter. I've
had some people say, "So should I stop using X and use Dist::Zilla instead?"
The answer is complicated.
(Well, actually, for now the answer is simple: probably not. Dist::Zilla is a lot of fun and I really, really appreciate the amount of work it saves me, but it's really young, underbaked, and probably full of bugs that I haven't noticed yet. Still, the adventurous may enjoy it.)
The idea behind Dist::Zilla is that once you've configured it, all you need to
do to build well-packaged CPAN distributions is write code and documentation.
If you're thinking, "but that's what I've been doing anyway!" then first
consider this: If you are writing =head1 NAME\n\nMyModule - awesome module by
me then you are not just writing code and documentation. If you are adding a
license to every file, again, you are not just writing code and documentation.
If you use, say, Module::Starter to get all this written for you, then you're
safe from writing that boilerplate stuff. Unfortunately, if you need to change
the license, or you want to add a 'BUGTRACKER' section to every module,
Module::Starter can't help you. It creates a bunch of files and then its job
is done. It never, ever looks at your module-started distribution and fixes up
things. This also means that if you realize that your templates have failed to
include use strict for your last three module-started distributions, you have
to fix them by hand. The same goes for the stock templates, which until
recently didn't include a license declaration in the Makefile.PL.
With Dist::Zilla this content is not created at startup. It is not stored in
your repository. Instead, the files in your repo are just the code,
documentation, and the Dist::Zilla configuration. When you run dzil build,
your files are rebuilt every time, adding all the boilerplate content from your
current setup. If you want to change the license everywhere, you change one
line. If you want to start adding a VERSION header, you tweak the Pod::Weaver
plugin's configuration.
So, there does exist a dzil new command for starting a new distribution. All
it really does, though, is make a directory (maybe) and add a stock
configuration file. Why would it add anything else? If you want any code, you
would only be writing the actual code needed, not any boilerplate, so adding
anything would be foolish.
There's also dzil release, which goes beyond what Module::Starter (and its
competitors) do and into the realm of ShipIt or Module::Release. I'm hoping I
can integrate with or steal from one of those sort of tools. Right now, it
exists, but all it does is build a dist and upload it. In the future, it will
have at least two more kinds of plugins to make the release phase more useful:
VCS (so it can check in and tag releases) and changelog management. It has a
changelog thing now, but it stinks and isn't very useful. In the future, you
won't need to edit a changelog. It will be able to read changes out of your
commits, or you will just tell it to record a changelog entry. Then the
Changes file can be generated as needed.
For now, I am manually editing my Changes file.
So, eventually Dist::Zilla could obsolete Module::Starter for people who like what Dist::Zilla does. Then again, people might still want to have starter templates that add minimal boilerplate for using certain frameworks. We'll see what happens.
This sounds like a cool idea, and I've often thought of a similar tool. However, the cool features take longer to implement than the brute force work they would save me.
I have my own solution to the starter template problem: Distribution::Cooker. It's a simple idea; make a directory of templates that set up a module just the way you like them then process them. There are no other design restrictions.
Re:I made Distribution::Cooker
rjbs on 2008-10-27T18:10:51
I saw you mention D::C recently, but haven't yet had a look.
Maybe I will be able to save you that brute force by implementing many or most of the features you'd want.
Unfortunately, right now my test suite is, "if I install the new Dist::Zilla, can I still ship my code?"
Hopefully that will get better, too...
Re:I made Distribution::Cooker
brian_d_foy on 2008-10-27T18:33:53
I'm not going to use Dist::Zilla, so don't worry about me. That's not a judgement on its potential, just a statement that I already have this figured out for my own process.
I should have included an example earlier to illustrate my point: If I want to change the license of code once, it's faster for me to edit the files than set up everything in a particular way to use a tool. If I continually have to change the license, then a tool might make sense. I almost never have to change a license though. No amount of extra complexity or work is going to help that common case, and any amount of extra complexity or work is going to hurt it.
Tools don't make things better or faster if they aren't applied economically.
Re:I made Distribution::Cooker
rjbs on 2008-10-27T19:11:10
Yeah, license was a poor example. More likely is something like the Perl Email Project code, where I had to change a zillion "current maintainer" or "see also" sections that could've been made into chunks for inclusion at dist-making time. Or the time that I decided I wanted to start putting "=head1 VERSION" in all my modules, but would've had to go add it to 200 files to do so.
I agree, though: I try not to write tools that I won't use. Often, I'm even successful.
