Recently, hanekomu was contemplating how to make subsequent installs of a Task::BeLike module upgrade its dependencies to their latest version.

The idea is intriguing. It’s not something you want to do for a typical module, but it makes sense in the context of Task::BeLike. If you care enough about a module to put it in your Task::BeLike, you probably care enough to want to upgrade when there’s a new version out there.

Alas, I think hanekomu’s proposed way of doing it is flawed (mind you, the debate is still going on as of the writing of this entry, and I can very well still be proven wrong). But after some pondeferous chin scratching, I might have come with a cunning alternative to it.

Let’s say that in your Build.PL (the logic would be the same for a Makefile.PL) you have your dependencies stashed in %dependencies. Something akin to:

%dependencies = (
    XML::LibXML      => 0,          # any version will do
    XML::XPathScript => '1.42',     # 1.42 or higher
    Moose            => 'latest',   # nothing but the shiniest!
);

All we want to do, really, is to switch the latest for, well, the latest version available. Surprisingly, that something that is almost as easy to do than to say:

for my $mod ( keys %dependencies ) {
    next unless $dependencies{$mod} eq 'latest';

    require CPANPLUS::Backend;
    state $cb = CPANPLUS::Backend->new;

    $dependencies{$mod} = $cb->module_tree( $mod )->package_version;
}

Yes, that’s really all there is to it. A little further hacking later, I have incorporated the functionality to my own Task::BeLike::YANICK module. The way I implemented it, installing the module the usual way will yield no surprise (i.e., dependencies already present are not going to be updated). But if the environment variable TASK_UPGRADE is set to true, like so:

TASK_UPGRADE=1 cpan -f Task::BeLike::YANICK

 . . . then the magic is going to be unleashed (the -f is to force the re-install, if the Task has already been installed before).

Alternatively, just to know which dependencies are out-of-date, one can also extract the distribution and do a

perl ./Build.PL --upgrade
./Build prereq_report

picture by Geophaps
Hey, that one in the sixth row…
Doesn’t he looks familiar?

So there I am, on my morning bus ride, reading my copy of The Definitive Guide to Catalyst (keep your eyes peeled for the upcoming review of the book in the Perl Review).

I’m near the end, in Chapter 11, Catalyst Cookbook. As it is with most tech books, the last chapters are the most engrossing, as the gloves finally come of and the writers throw at you all the wonderful, mind-bending stuff that the rest of the book prepares you for.

The section I’m at is about the development process. Specifically, it shows how you can put hooks in your versioning system to automatically screen commits to conform to Perl::Critic and Perl::Tidy policies. The given example script uses Git, which is just dandy with me as it is my current VCS of choice. But there’s something . . .  funny about that script. The way the utility functions are stashed at the end after a

### utility functions ##############################

line. The choice of variable names. The comments. It all feels oddly familiar. And then my eyes fall on the line

exit 0 unless @dirty; # Alles gut

and everything falls into place. The script in the book is a wee bit different and has been improved upon, but its origin is unmistakable. Somehow, unexpectedly, a hack of mine found its way into publication. Fame, glory, and page 293 of the Catalyst book, I can finally claim ‘em all as rightfully mine!

But, serendipitous glee aside, three important lessons lie in this little story.

1. Blog posts, great and small, the Perl Gestalt, it reads them all

All clever tricks, code snippets, and insights you come up with? Blog ‘em. Even if you think they are only an itsy widdly little bit clever. Chances are, if there is a spark in there, it’ll ignite the mind of someone insaner than you are and ultimately result in something awe-inspiring. Or, more importantly, something awe-inspiring for which you’ll have bragging rights.

And don’t despair if your blog entries mostly go without comments. Provided that you are broadcast by an aggregator or two, people will read you. Silently, furtively, your thoughts will slip in the Perl subconscious like so many pumpkin seeds into autumn soil.

2. Code carries your DNA

No big discovery here, but it’s interesting to see how surprisingly easy it is to recognize one’s own code. One would think that nothing looks more like a line of code than another line of code, the same way nothing looks more like a baby emperor penguin than another one.

Yet, we do recognize ours by a curve of the beak, a specific timbre of the voice. Admittedly, Perl’s flexibility provides much more latitude for transposing our idiosyncrasies unto our digital babies. But then again, isn’t why a lot of us love Perl so much?

3. Some of my code made it into a Catalyst book!

I mean, seriously, how terminally cool is that?!