I wrote this some time ago, and it sat in the queue and got stale. I’ve mentioned one place I’m not using Config::JFDI, but I’m using it other places and I thought it desrved a mention.
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.
Tags: Catalyst, config, Config::JFDI, Perl