[Purdue-pm] On The Proper Use Of Config Files
gizmo at purdue.edu
Wed Jan 21 10:51:58 PST 2009
-----BEGIN PGP SIGNED MESSAGE-----
Dave Jacoby wrote:
> The Use Perl journal post from Alias yesterday brought up a question I
> have had for a while. I've been thinking about configuration files.
> I have of course rolled my own more than once. I have also read and
> parsed variables out of the ENV variables for web apps before I
> discovered CGI, and I would occasionally try to get my own options
> before Conway pointed me to Getopt::Long. With my most recent attempt, I
> realized that I could include abstract code into my config, which seemed
> to be a security hole in the making.
> So, went to the books.
> The Perl Cookbook 2nd Ed (8:16) suggests you roll your own.
> Perl Best Practices (19:3) suggests you use a module.
> (We're all Purdue people, so if we're at work [or can tunnel] we should
> all have access. And you should have PBP anyway.)
> My instinct is to follow Conway here. I have some Alias-inspired
> Config::Std-using code on the Wiki.
> But to what extent is the test I do necessary? To what extent is it
> sufficient? More for following PBP than the other way. If I can't trust
> CPAN modules, how can I use CPAN modules to help me test and trust CPAN
I would say that _Mastering Perl_ might be a good suggestion as well:
brian d foy goes over different ways folks do config files and modules
The premise in the book is that programming is like a craft and this
book is a way to get from a journeyman coder to master coder.
- From a quick scan of the chapter again I would say that AppConfig looks
to be the most flexible. He seems to lean towards INI style config files
but I think he would agree that it probably depends upon who will be
tweaking the config file. If it's just you then no big deal. If it's
someone else it's best to get their input.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the Purdue-pm