Sam's Blog

To Dist::Zilla, or not to Dist::Zilla?

Date: Saturday, 24 July 2010, 22:10.

Categories: perl, ironman, dist-zilla, module-authoring.

I maintain 38 Perl modules across 5 distributions on CPAN, which by the standards of some authors puts me firmly in the small fry category.

Nevertheless, the logistics behind each release does tend to drag after the 78th time. (Not that I'm counting.)

For example, bumping version numbers on each of the, 22 and rising, plugin modules for Template::Benchmark is just the sort of mindlessly repetitive thing that screams out to be automated, but I end up doing it manually each release.

Now this sounds exactly like a job for Dist::Zilla, so why haven't I switched?

Sources aren't the final product

The number one concern I have is that in all the really useful bits of Dist::Zilla, the bits that I really want to use, they modify the source code as part of the build/bundling process.

This means that my files in ./lib aren't the final product, which means that the files in my version control aren't the final product, which means that I can't just do a:

cvs checkout -r CPANv1_01_03 Template-Sandbox

and know that I've got the exact code that went into that release.

Sure, I keep archives of the released tarballs, and there's always the BackPAN, but I like the peace of mind of knowing that my VCS has the real deal in there.

I also like to use my current working checkout as the version used by all my development projects, this helps me spot issues and test out usage, profile, and so forth, all without having to install. If that version isn't the final product, I'm losing the advantages gained there.

I could run from the build dir, but then the build dir doesn't always exist, it tends to get nuked by ./Build clean or ./Build realclean, and I'd hope that Dist::Zilla is similarly tidy.

Even if the build dir was there, I'd have to remember to do the build step each time I wanted to insert a debug print statement and flip back to whatever window is doing debugging. I can do without adding extra steps to my devel cycle, eliminating extra steps is the whole point of the exercise in the first place.

I've seen a few other people posting about hitting this stumbling block and I've not seen anyone mention a solution yet, it seems the people who use Dist::Zilla either don't use those bits, or they just don't find it a problem.

I can't seem to find out if there's a way to make Dist::Zilla do what I want.

So what is it that I actually want?

Well that leads to an interesting question, what is it that I actually want Dist::Zilla to do for me?

Well I don't really care about uploading to CPAN, I'm quite happy to do that manually, as a safety check that I really am sure I want to release.

And I don't really care about building the tarball, because, well, Module::Build does that for me already quite happily and I'd need to carry on using that for the install bits anyway.

I do want to automate bumping version numbers, I do want to automate keeping licence text and copyright dates and other boiler-plate up-to-date.

Extracting the README from the main POD would be great too.

Most of all though, what I want is to be able to have these tools work as in place edits.

The same way that I can update my MANIFEST file at any stage of my development process with:

./Build manifest

I want to be able to do something akin to:

dzil bump-version-numbers 1.03_07

And after that command, all the version numbers are bumped to 1.03_07, and I can check those changes in as if I'd manually done the edit.

Ditto for doing my boiler-plate updates and so forth.

I can't see an easy way to do that with Dist::Zilla, and I don't know whether that's just me not seeing it, or whether it's simply that Dist::Zilla can't do it.

I want to make those changes as part of the editing/development process whereas Dist::Zilla wants to do them as part of the release process.

Maybe that's the problem, that Dist::Zilla isn't the tool for me, and what I need is some other tool that hasn't been written.

That would be a shame.

Browse Sam's Blog Subscribe to Sam's Blog

By day of July: 01, 07, 15, 24.

By month of 2010: March, April, May, June, July, August, September, November.

By year: 2010, 2011, 2012, 2013.

Or by: category or series.


blog comments powered by Disqus
© 2009-2013 Sam Graham, unless otherwise noted. All rights reserved.