I mentioned my old framework had a way to infer which configuration file to use by examining the environment it was running in.  I’ve moved to the Catalyst Way of things (more or less) and that will make things easier.  A bunch of my old code can go away.

I have some useful tools to do things which do like to read the config file, too.  They used the same code.  They now use Config::JFDI.  It reads config files the same way Catalyst does, and gives you a very similar $config object you can use to look at things with.

I did have to dig in to the sources to get it to work right, even though it’s pretty well documented.

When I run my programs, I usually run them from a shell where I have environment variables set to get the right suffix for my config files.  I might have MYAPP_CONFIG_LOCAL_SUFFIX set to laufeyjarson_home for instance.

There was a case where the utility program needed to force a particular value there, so it would get the right configurations.  I called Config::JFDI->new with local_suffix=>’whatever’, and expected that to work.

It didn’t seem to. The documentation said it works!

And, it does work.  But it only works if the environment variables are not set.  If the environment is set, that overrides the values set with new().

I almost filed a bug on it, too.  That can’t be right!

It can, though.  I just had to think it through.  You want your program to have a sensible default coded in.  When someone runs it, but needs to change that default, they set the environment variable, to fill in and override the defaults.  That’s exactly what it did!

Too bad it isn’t what I wanted.

Config::JFDI supports an option to new called “no_env”, which will tell it not to read the environment.  That would fix it.

I actually went the other way; I changed ${ENV}.  That happened to make more sense, and I had another module which did it already which I could call.

So, Config::JFDI works right, and lets you do whatever you need.  It’s also really handy to write stand-alone tools with it and have it work like Catalyst does.

I was  considering using it in myapp_server so I can set only MYAPP_CONFIG_LOCAL_SUFFIX or CATALYST_CONFIG_LOCAL_SUFFIX and then put the default values for all the command line options in my config file rather than in four more variables.  Decided not to.  I just set the environment and let it be.

I had struggled with Config::JFDI and tried to create DBIx::Class objects outside of the Catalyst models so they could be used standalone.  This sort of worked, but wasn’t as easy as I wanted.

I found a way, and it’s so simple it hurts.   I can’t help think this is one of those things the Catalyst team will read and think, “Well, duh!” but it was never clear to me and I struggled with it for months.

Make sure MyApp/lib is in @INC and use MyApp.  Catalyst is loaded, along with all the details of your application.  No Engine is running, so it isn’t a server.  You can then call methods listed for Catalyst, as MyApp uses it as a parent.

The key to this is that Catalyst::model and Catalyst::view can both be called as class functions or as methods.  You usually seem them as $c->model() and $c->view, called off a context object.  They can work as MyApp->model() and MyApp->view(), too.

So, your tool does:

use MyApp;

my $foo = MyApp->model(‘Model::Whatever’)->search({ name => ‘foo’ })->first();

… or whatever thing it needs to do.  The config is loaded with all the MYAPP_SUFFIX parsing as you would expect.

A problem I couldn’t for a year and a half has finally been solved.  YAY!

The biggest quirk is that if MYAPP_DEBUG is set, or the app has $c->debug on, the debug output will happen when the module loads.  For the tools I’m writing that isn’t a problem, but it could be for other applications.

It’s actually pretty easy, but it wasn’t obvious, at least to me.  It is on the debugging page of the Catalyst tutorial, but I missed it the first dozen times I read the page.

As a note, if you haven’t gone all the way through the tutorial yet, it really is the best place to start.  It tries to touch most of Catalyst and gets a lot of things right.  It is extremely dense, and you’ll have to go over it a lot before you see everything on the pages.  Or at least I did.  For instance, I just noticed the Task::Catalyst::Tutorial module, which will install the tutorial and all the dependencies in one go.

Back to debugging Catalyst.

Catalyst is written as a large collection of modules.  Even your Catalyst app is actually a module that is used by the server application.

The server application is the myapp_server.pl or one of the other scripts in the scripts directory.  These are provided by the catalyst.pl.  None of my programs have needed to change them at all.

Your code, like the rest of Catalyst, is libraries.

The server program sticks “lib” in @INC so all the modules you have written as part of your application are read.  It puts that early in @INC so that your programs are loaded before other library paths.

You can use this to debug the Catalyst libraries as well.

Find the library module you want to edit.  My most recent example was ConfigLoader.  The full name of that module is Catalyst::Plugin::ConfigLoader.  It should be in Catalyst/Plugin/ConfigLoader.pm, either in your local library path (such as ~/perl) or in the system library path (something awful like /usr/lib/perl5/site_perl/<version number>/), depending on where you installed it.

In your Catalyst application’s lib directory, create that same hierarchy, and copy .pm file there.  Instead of finding the one in the system path, it’ll find the one in myapp/lib/Catalyst/… first.

The example above was copied from /usr/lib/perl5/site_perl/5.8.8/Catalyst/Plugin/ConfigLoader.pm to ~/projects/MyApp/lib/Catalyst/Plugin/ConfigLoader.pm.  Then I scribbled a bunch of “print STDERR” statements in my copy so I could see what it was doing.

In my last post, I mentioned how the Catalyst documentation uses MyApp as the sample name for your application.  My note up there is actually literally correct, because I created a new, empty Catalyst app to test with.  I called it MyApp.  I erased it when I was done.  It’s a handy technique to simplify testing.

To recap, you can copy any part of Catlyst from the place it is installed to myapp/lib, maintaining the directory structure, and the one in the application will be loaded before the one in the library paths.  You can then use and edit that file as much as you like, without messing with the installed copy.