Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

rjbs (4671)

rjbs
  (email not shown publicly)
http://rjbs.manxome.org/
AOL IM: RicardoJBSignes (Add Buddy, Send Message)
Yahoo! ID: RicardoSignes (Add User, Send Message)

I'm a Perl coder living in Bethlehem, PA and working Philadelphia. I'm a philosopher and theologan by training, but I was shocked to learn upon my graduation that these skills don't have many associated careers. Now I write code.

Journal of rjbs (4671)

Monday October 27, 2008
10:58 AM

what the heck is distzilla?

[ #37749 ]

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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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 [cpan.org]. 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. :)

    • 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...

      --
      rjbs
      • 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

        • 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.

          --
          rjbs