[Wellington-pm] Complex config files

Grant McLean grant at mclean.net.nz
Wed May 13 18:42:22 PDT 2009

On Thu, 2009-05-14 at 13:13 +1200, Lesley Longhurst wrote:
> I'm interested in recommendations for a good module to use for reading 
> and writing complex config files.

This is one of those area where "there's more than one way to do it" and
the decision generally boils down to personal preference.

I used to think that XML was a good choice for such things.  In fact the
reason I wrote XML::Simple was to parse config files like this:


Unfortunately projects like Tomcat took to XML configs in a big way and
the results were universally hideous.  XML is no longer a popular

The example you posted of the direction your thoughts are heading is
remarkably similar to YAML.  The problem with YAML is that for humans
it's read only.  Sure, in theory it's possible to open a YAML file in a
text editor and change it - good luck with that in practice.

JSON is kind of like YAML but much simpler (the YAML spec is even bigger
than the XML spec).  It's more free-form than YAML so as long as you
stick to a few simple rules it's much harder to screw up.  JSON files
will need to contain syntax elements like [ .. ] for lists and { .. }
for hash-style key/value sets.  I think that makes them clearer and more
explicit than YAML but that's just one opinion.

An advantage of XML (at least in theory) is that you can validate a
config to ensure it is syntactically correct and that it conforms to
some sort of schema.  If there is an error in your config file it's far
preferable to be told immediately than to have things appear to work and
then fail in mysterious ways later.  I recommend RelaxNG for schemas,
but if you go down that route it may seriously increase the number of
extra modules you need on every machine where your code runs.

Even without XML, it's possible to validate the format of your data
structure (ie: what keys are allowed, what the valid set of possible
values is etc) at the Perl level.  Data::Rx is a modern tool for this.

The other advice that I would offer is to write your own class for
reading config files.  Even if you end up using YAML, XML or something
else, all your custom stuff will be in one place - rather than scattered
through a bunch of scripts.  If you need to fix it or change it then
you'll only have to do it in one place.  Your scripts might include one
line like this:

  use MyAppConfig qw($app_config);

and that might be enough to identify a configuration file based on the
script name (in $0) or command-line arguments (in @ARGV); read and
validate the file; and return the results as say a hashref or even an
object directly into the variable '$app_config'.

There are many ways you could do it but you'll want to keep the
per-script overhead low.


More information about the Wellington-pm mailing list