2010 Grant Proposal: Improve Dist::Zilla

Category: Grants

Comments (6)

i totally support rjbs' grant.

i've been converting my modules to use dzil, and the results so far have been impressive:
- the lines of code & comments in my module repositories have shrinked quite a lot, since dzil generates so much boilerplate that i used to write by hand and record in the project repository
- i'm now able to release new versions in a breeze, allowing for more frequent releases... and of better quality, since all the tedious and error-prone work is now done for me automatically by dzil
- finally, i'm not afraid to create new distributions, knowing that i'll be able to concentrate on the code and the core problem i'm trying to solve. check: i've created around 10 new dists in the last 6 monthes, in large part thanks to dzil!

so, this was for dzil's usefulness. now, what about this grant? well, currently, dzil is really great, but is still in its infancy. i've created some dzil plugins, and contributed some patches to dzil, and the enhancements that rjbs propose will greatly ease the inner work on this module... and since more and more people are now using dzil, it makes sense to have this toolchain module as robust as eumm, test::more and others. moreover, some parts of this grant will allow beginners to get on board with dzil quite easilly.

also, rjbs has a long record of striving for utility module extraction: if sthg of general use can be made as a release of its own, rjbs will do it... for the greatest reuse of all perl authors.

finally, rjbs already showed that he delivers what he promised - and often even more. so by granting funds to this proposal, you know that you invest in sthg that will produce results, and results used by a lot of cpan authors.

in conclusion: i really wish this proposal to be approved.

-- jérôme

I've been "teetering on the edge" of using dzil for a while now but haven't made the plunge.

It's clear from Jérôme's comments, and elsewhere, that there's significant benefit from using dzil. For example "i've created around 10 new dists in the last 6 months, in large part thanks to dzil". That's clearly a significant benefit.

My problem has been finding the time to climb the learning curve. I don't want to have to read the docs for ~26 plugins to decide which to use, and how, for a simple distribution. So I cop-out and do it the old way. The barrier to entry needs to be lower for lazy people :)

For new modules I want to type in a single command giving the name of the new distribution, and perhaps a few options, and get a whole new directory tree with a 'best practices' dzil setup. Perhaps that means integrating with something like Module::Starter in some way.

The proposal suggests supplementing the existing Dist::Zila::Tutorial, starting from the position "So you want to release code to the CPAN...". Supplementing the tutorial would be great, but I think two starting positions are needed: one for people starting a new module from scratch, and another for people integrating dzil into an existing module (*cough* DBI *cough*).

Anyway, incase it's not clear, I fully support this proposal and trust rjbs to do a great job.

-- Tim.

Thanks for your support, Tim.

You mention "integrating with something like Module::Starter." For a long time, I didn't understand what people meant by this. My goal with Dist::Zilla was to eliminate the boilerplate built my Module::Starter, so the tool became redundant. As time went on, though, I got a lot of good input on the idea, including how it would be useful in many cases.

A few of the tasks above, especially "event structure for distribution creation" go toward making it easy to use the "dzil new" command as a Module::Starter-like tool, without the baggage of Module::Starter, which is pretty painful to extend (and that pain is largely my own fault, sadly).

Like Tim I haven't used Dist::Zilla but I've looked at it and the source for some of rjbs's modules and I'm impressed that it generates all the nasty boilerplate that I maintain manually.

It would be very good to get better documentation for it however, and support for XS modules.

I support this proposal.

I'm another person the list of "would like to use dzil but got hung up on the docs". In particular, I agree with Tim that some docs specifically on how to integrate dzil into an existing module are sorely needed.

All of this is to say that I support this grant.

As an aside, I think that the related Pod munging modules either need more docs, or dzil needs docs on how to use them, or some combo of the two. This is where I really got hung up on trying to use dzil last time. My main motivation was to reduce doc boilerplate but I just could not figure out how to add custom sections to the pod weaving process.

Thanks, Dave.

I agree (obviously, hence this grant!) that the documentation is sort of helter skelter right now. Dist::Zilla is unlike most of my other work, and unlike most Pod-documented libraries because almost all of its functionality comes from plugins. It's become clear that just documenting each module isn't sufficient (who wants to read 25 short man pages?) and I need to write a proper introduction and manual. I'd like to produce a Pod-based manual, but I think it is unrealistic, and that I am more likely to produce an HTML and/or PDF manual with diagrams and sidebars.

Pod::Weaver is likely to be touched upon by this documentation, but I don't think it's likely to get the same full treatment merely by virtue of the grant. On the other hand, I will have to execute the documentation of such a system, so it will be much easier for me to document Pod::Weaver after I've documented Dist::Zilla!

Sign in to add comment