Dist::Zilla eases management of your CPAN distributions

By Ricardo Signes

At the Pittsburgh Perl Workshop this year, I gave a lightning talk about
, 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 NAMEnnMyModule - awesome module by
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.

Ricardo Signes was thrust into the job market with only a rudimentary humanities education, and was forced to learn to fend for himself. He is now a full-time Perl programmer, maintainer of the Perl Email Project, and frequent contributor to the CPAN.

Perl 6 isn’t exactly vaporware

Infoworld blogger Neil McAllister referred to Perl 6 as having “graduated to vaporware”, and chromatic dissented. McAllester prints a lot of chromatic’s letter and adds his own commentary, and it’s a good read.

I’m glad chromatic wrote it, and McAllister ran the article, but the fact still stands that Perl 6 is vapor enough for most organizations wanting to do anything useful. The fact is that most organizations and users are going to wait for Rakudo Perl 1.0, or maybe Rakudo Perl 1.0 beta 1, before they start sniffing at it.

I wonder how we can merge these two concerns. How can we let people know about the Perl 6 that is usable here and now, such as the November wiki package written in Perl 6, and the features that people can use today and rely on not changing, while still acknowledging that Perl 6 isn’t at the state that people will want to count on?

Does there need to be Rakudo Perl Early Adopter Edition, for example? I understand that any given Rakudo build could be Early Adopter Edition, but I’m talking about releasing and publicizing something that is specifically called that.

(Also, please don’t bother explaining WHY Perl 6 is at the state it’s in. I know why, and the people who are waiting for 1.0 don’t care why. That’s not the point of my question.)

Creating a module distribution with Module::Starter

As Chris Prather pointed out in Write your code like it’s going on CPAN, Perl’s module toolchain is getting better every day, and the support for good coding habits can help even if you don’t want to distribute your code. However, starting a module distribution from scratch can be a daunting task.

I wrote Module::Starter a few years ago to make it easy to create a module distribution, but never wrote the kind of basic introduction that it needed. Now, Perl Training Australia has done just that with one of its Perl Tips, Starting a module with Module::Starter. I’ve already absorbed it into the Module::Starter distribution.

Module::Starter does happen to be getting a little long in the tooth, and I know that Ricardo Signes, for one, has started his own module creation magic. If Ricardo or any other authors would like to let Perlbuzz readers know about their projects, let me know.

Write your code like it’s going on CPAN

By Chris Prather, from his recent blog entry

One of the things I’ve discovered recently, and wished I’d known years ago is you need to write all your Perl applications like you were gonna be posting them to CPAN, even if you have no intention of ever doing so.

At work we are starting to migrate from a legacy system that was written in the grandest of late 90s CGI (the code is clear, easy to read and for this era of script well documented, but lacks any architectural cohesion and has been patched and re-patched over the years to handle new use cases). This system is absolutely core to our daily business. You might even argue that it is our daily business.

One of my tasks was to add Validation on some of the input parameters. My boss wants to move to something testable so I created a Validation module that contained a bunch of validation functions for the various pieces of data, and when we could easily do so we wrapped CPAN validation modules (Regexp::Common we love you!). This however added a couple of new dependencies to our system. This is where writing it like a CPAN package comes in.

I added a Makefile.PL for the system. We have no intention of ever releasing this code, but the Makefile.PL uses Module::Install and lists the dependencies. The magic of this is that for recent versions of cpan you can just type cpan . and it will automatically install all the dependencies for the current directory. Failing that you can always run perl Makefile.PL && make && make test and it’ll install dependencies and run your test suite.

By treating code we were never going to release to CPAN as if we were, we win the support of all of the CPAN toolchain. A toolchain that is getting better every day.

Chris has worked with Perl for 7 years in 3 time zones. He’s responsible for Bender on irc.perl.org, and MooseX::POE. He is happy to be back in Florida where it is warm.

Using HTML::Table::FromDatabase

By David Precious

A task I find myself doing reasonably often when programming is producing a HTML table based on the result of a database query.

This often ends up with the same kind of boring code being written again and again, which get tedious.

For example:

<table border="1">
my $sth = $dbh->prepare(
"select id, foo, bar from mytable where something = ... "
$sth->execute() or die "Failed to query";
while (my $row = $sth->fetchrow_hashref) {
print '<tr><td>';
print join '</td><td>', @$row{qw(id foo bar)};
print "</td></tr>n";
print "</table>n";

Not hard, but it does get tedious.

HTML::Table makes things better by taking out most of the HTML drudgery, but you still
need to loop through adding rows to your table.

This is where my HTML::Table::FromDatabase comes in – it’s a
subclass of HTML::Table which accepts an executed DBI statement handle, and automatically produces the table for you.

For instance:

my $sth = $dbh->prepare(
"select id, foo, bar from mytable where something = ..."
$sth->execute() or die "Failed to query";
my $table = HTML::Table::FromDatabase->new( -sth => $sth );

Much easier, and HTML::Table::FromDatabase does all the tedious work.

Sometimes that won’t be quite flexible enough though; you might have something you want to do to certain columns or values before
outputting them.

That’s where HTML::Table::FromDatabase’s callbacks come in handy. For a basic example, let’s say that one of the columns
you’re fetching contains URLs, and you want to wrap them in anchor tags to make them clickable links. Simply done with:

 my $table = HTML::Table::FromDatabase->new(
-sth => $sth,
-callbacks => [
column => 'url',
transform =>
sub { $_ = shift; qq[<a href="$_">$_</a>]; },

Another example – looking for all cells whose value is a number, and formatting them to two decimal places:

 my $table = HTML::Table::FromDatabase->new(
-sth => $sth,
-callbacks => [
value => qr/d+/,
transform => sub { return sprintf '%.2f', shift },

You can apply as many callbacks as you need.

As HTML::Table::FromDatabase is a subclass of HTML::Table, all of HTML::Table’s options can still be used to control how the generated
table appears, for example:

  • -class => ‘classname’ to give the table a specific class to help you apply CSS styling
  • -border => 1 to apply borders, -padding => 3 to set cell padding
  • -evenrowclass and -oddrowclass if you want to have different styling for even and odd rows (e.g. alternating row

The full list of options can be found in the HTML::Table
documentation, I’m not going to duplicate it all here.

Currently, the row headings used in the generated table are taken from the column names in the query, but I plan to release a new version
sometime soon which allows you to alias them, if you want to do so.

(The code samples in this post are intentionally kept relatively simple, omitting obvious things like connecting to the database first,
error checking etc).

David Precious is a professional Perl developer, currently working for a UK web hosting company. He has released several modules on CPAN, and contributed to a number of other Open Source projects. He’s also a keen motorcyclist, and has a fondness for beer.

Plain Black puts five years of conference video online as WebGUI TV

Plain Black, the guys that put out WebGUI and give out the purple octopi at YAPC and OSCON, have put five years of WebGUI conference videos online at www.webgui.tv.

Tavis Parker of Plain Black writes:

WebGUI TV (WGTV) is a free video library containing archival footage of past WebGUI Users Conference presentations, as well as videos from other training resources. Close to 150 videos on all topics related to WebGUI are currently available, and the collection will continue to grow!

Perl developers will be pleased to hear that WebGUI TV includes several presentations on topics such as basic Perl programming, object-oriented Perl, WWW::Mechanize, Test::More, and mod_perl development. These topics are very relevant given that WebGUI is the most comprehensive and widely used Perl content management system available. Aside from being a popular CMS, WebGUI has also become a widely used application framework for building web apps.

To learn more about WebGUI TV, read JT Smith’s announcement in The Black Blog.

Most of the videos seem to include the slides for download, too. Many of the talks are about WebGUI itself, but there’s Perl-specific content, like Chris Dolan talking about Perl::Critic, Writing with YUI and so on.

Thanks to JT & co. for making this available. I’ve been to so many conferences where there are cameras around, and you just hope that the video will get uploaded, and it rarely does, and certainly not as complete as this archive.

Pittsburgh Perl Workshop 2008 is underway

John Cappiello writes:

So far I am enjoying the hallway track as always. Buglabs was semi interesting, but the business / product seems impractical, Rx talk by Ricardo Signes was both entertaining as always, and hopefully an informative piece to some, as it’s quite an interesting product.

There’s only one track today, so talks are limited. I’ll send more info as it comes along, and I have more conference photos to be uploaded to Flickr already. They’re all tagged ppw2008.

Any other reports from the field? Link to them in the comments!

What’s the state of Perl web frameworks?

Joshua Hoblitt pounced on me in AIM this morning as soon as I opened my laptop.

Joshua Hoblitt: Here’s something to put on Perlbuzz.

JH: WTF MVC framework is working this week?

Andy Lester: Sounds like an editorial in the making?

JH: Maypole is dead,
Catalyst is um, well, I’ve never managed to finish a project with it.

JH: The documentation is SHIIITTT.

JH: And the book is one of the most crapped-on books I’ve ever seen on Amazon.

JH: So Catalyst is a no go for me.

JH: So what’s left? Roll your own with Mason?

AL: CGI::Application?

JH: Ya, I’ve used it for small stuff.

JH: The kind of stuff you put in one monster .pm file so it’s trivial to install.

JH: Hmm, there’s MasonX::MiniMVC.

JH: And this egg thing.

AL: Can I post this chat as an article?

JH: Please do.

I’ve gone through a similar thought process recently. I’ve started looking at CGI::Application, but
the work project where I was starting to use it has been derailed for a weeks.

I welcome your ideas on the state of frameworks, either in comments below, or as a guest editorial.