« Perl 5.14 Stable Release! | Main | Seeking Venue for Teaching Modern Perl »



Feed You can follow this conversation by subscribing to the comment feed for this post.

Alexei Znamensky

Hi John, I have been using dzil with my (few) projects for a couple of months now, and so far I gotta tell you that it has been worth every minute spent in the initial setup.

As with 'rolling my own', I have been trying to stick on the widely-used tools, but I feel that if I find that I need something more specific, I can develop a plugin for Dist::Zilla and get it done with.

I agree 100% that Moose is heavier than it should, more than perl stuff ought to be, anyway. But then again, most of the good things we have today started from bloated ideas. The more we use Moose, the more we will be able to polish it and turn it into a fast beast.


Thanks for your thoughts! Just to be clear, regarding Moose and dependency weightiness, I personally don't feel Moose is particularly heavy and use it extensively. I want to be clear on that. Just I have a bit of nervousness in requiring it for someone to contribute to any of my CPAN distributions, particularly if the distribution dependencies are trivial. I don't want someone to think, "I just want to offer a Documentation Patch and extra test and I need to install all this stuff? Forget it."

For those of you using DistZilla, are you finding this to be an issue or not?

Alexander Hartmaier

I had to get used to dzil when I got involved into DBIC::API.
Newer dzil versions added commands like authordeps that make installing the required modules a breeze.
It took me about a day to find the plugins, mostly testing ones, to make it even more useful for our in-house modules.
I don't like the idea of bundles that much because a change to them might break the build process of any module using it.
When I find a new useful plugin I add it to my modules one after the other and verify that it works.
Lately I had to install three author-only requirements for a Module::Install based module one after the other by hand because M::I only reports the first missing module on failure. That clearly showed that contributing to a dzil based module might even be easier!

fREW Schmidt

I love the ease of use that dzil adds, but I really *don't* like how unmalleable it is. rjbs is an architecture astronaut for sure, but what that means for the rest of us is that either it's super difficult to figure out how to make something work, or you just can't, because an interface wasn't already created for it. I made a thing for dzil that would automatically generate some ddl when the dist is built. It works, it's just kinda gross and wasn't easy at all to write.

Caleb Cushing ( xenoterracide )

I like dzil, and I wouldn't worry too much about contributer's personally. I keep both a 'built' version and a 'source' version in my git repo so if someone wanted to run all the tests they could just run them against the built repo. Also generally for a doc patch that wouldn't be required anyways.

Ricardo Signes

Contributors to my dists that use dzil don't need to install Dist::Zilla or the plugins I use. I only ask that patches still pass with "prove -lr t"


It's worth it IMO.

If you are worried about contributors needing to use dzil to contribute to your project, just use the Git::CommitBuild plugin, and publish the branches that you have it configured to build on. That way the dzil output is also available so contributors do not need to worry about dzil at all.

brian d foy

I don't use dzil, and I don't make patches for distributions that use it. I don't even consider it. I don't like reporting issues without patches, so I tend to skip reporting the issues too unless it's really important to me.

Talking to rjbs at the 2011 QA Hackathon, he said that he created dzil for his particular situation where he hardly ever gets patches. He gets plenty of feedback, but not patches. He does take patches based on the distro, but then he has to then port those patches to the sources.

When I started running into dzil distributions that I wanted to patch, I started to install dzil, but with all of the plugins that people use, it gets to be a hassle. When I'm on a machine where I haven't set up the tools that I personally use, that's a bunch of work for no benefit. Even then, I have to figure out what to patch for the right thing to show up in the distribution.

If you are using it for things you don't expect anyone to contribute to, you are probably fine. If you expect other people to contribute, especially random people who've never heard from, you're erecting a huge barrier to participation. Mschout mentions the "just use ..." fallacy, but that's work too, and only works when you already know what that does.


I share brian's opinion: $dzill--


Hi, John. I encourage you to go read (re-read) my post, "Why I'm using Dist::Zilla". It walks through several examples of what dzil can do, ranging from just release management, through to more complex usage with auto-generated files. Depending on how much you choose to have dzil do, you can tradeoff what it does for you versus what might confuse others.

To brian's point, dzil is "optimized" for authors and distributions where the number of one-off contributions is low. In my experience, that's 90%+ of what most CPAN authors have. dzil optimizes for me because I'm still doing most of the work. In a large community project, that might not be the right tradeoff.

On the other hand, you don't need dzil to work on a dzil distribution. Most of them can be patched from a repo and tested with 'prove'. (There are some few exceptions, particularly if dzil manages $VERSION for you and your code depends on it, but I've found those to be rare.)

The only person who really needs dzil is the person releasing it.

I think the "contributor unfriendly" issue is mostly a documentation failure -- I think most dzil distributions could use a short README.HACKING file that explains how to contribute without (and with) dzil.

I have not used the CommitBuild plugin but I think it would help make distributions more contributor friendly.

I see dzil in a progression of optimization attempts. M::B optimized for authors at the expense of end-users. M::I optimized for end-users (supposedly) at the expense of authors. dzil optimized for authors *and* end-users at the expense of casual contributors.

-- dagolden


Hey Everyone!

Thanks for the thoughts and suggestions. I think I will try converting one of my non CPAN personal projects first and see how it goes in-house. It would be nice to be able to point developers at documentation, rather than my hastily written notes on my 'rolled it myself' Module::Install based system. And I could probably convert one or two of my Moose projects since Moose is one of the bigger DistZilla dependencies anyway. Right now I don't see any other options that has as much community mind share.

I will try not to use too many of the fancy plugins either, that seems to be one of the things that turns people off.

The comments to this entry are closed.