Catalyst::ScriptRunner

Summer of 2009 brought some great things, and one of these things was my being accepted into the Google Summer of Code! My project was to refactor the Catalyst::Helper API and Catalyst::Devel package into something a little less hateful. And I accomplished this, more or less.

Application skeleton files are now in a sharedir

The application skeleton files are now stored in a sharedir, making it much easier to alter / patch the content of generated applications. Component authors can also now use a sharedir, and can use the the extra render_sharedir_file method to get templates from a sharedir generated by their Helper class.

Scripts are now Classes

The scripts, instead of being entities on their own, now just delegate the work to a ScriptRunner class which finds a script class, loads it, makes an instance, and invokes its ->run method.

If you open up a new script, you'll see something like this:

    #!/usr/bin/env perl

    use Catalyst::ScriptRunner;
    Catalyst::ScriptRunner->run('MyApp', 'Server');

    1;

As opposed to 100+ lines of development server logic.

What does this do for me?

This means that fixing bugs in the scripts is significantly easier and less hassle for you, because new scripts are included in Catalyst::Runtime. Therefore you get the benefit of them just by upgrading, rather than having to regenerate your scripts.

Also, you can write custom scripts, or easily add options to the existing scripts. This is Really Good if you want to hack your own server with additional command line flags. If you create a class called MyApp::Script::XXX, then Catalyst::ScriptRunner will pick it up and run it in favor of the built-in script.

Authors of alternate engines should also be able to reuse Catalyst::ScriptRole, provide a Catalyst::Script:: class and a Catalyst::Helper:: class, and then generate myapp_engine.pl scripts for the user which work just like the other scripts, without duplicating all of the script code.

Gitalist is an example of an application already taking advantage of per-application scripts to provide a --repo_dir option.

Application skeleton now uses Moose

The generated application skeleton has been tidied up in a number of ways, and now generates applications which use Moose and namespace::autoclean, tests which use done_testing , and which turn off some deprecated features.

That's all folks, short and simple.

Hopefully you'll think of some cool and fun uses for the new scripts and Helper code, and you'll blog in your Ironman blogs about them, or come chat to us in #catalyst-dev about what you'd like to do if it doesn't seem obvious.

This new work is a good basis for people being able to do cool things, but I'm sure there is some work still to be done to make it easier when people start experimenting with their real life use-cases.

- Devin "dhoss" Austin, and thanks a boatload to Tomas Doran for reviewing and beefing things up in this article.