Recent site activity

Config::Loader wiki

$nConfig::Loader is intended to be the new standard method of loading configuration data in Perl.


Intended features

  • able to merge data from multiple directories, files, databases, environment variables and user preference files
  • in its most basic form, provides sane defaults, which just DWIM - very little code required to use
  • ability to override single config keys for a local setup (eg dev)
  • complete control and extensibility - pluggable handlers and callbacks to alter the logic of loading and merging data
  • moose compatible
  • lazy loading
  • ???


What Config::Loader is not

  • a new config file format.  Instead, we can use any of the existing formats, as per Config::Any, but adding interfaces to DBI / DBM::Deep / GetOpt, ENV etc
  • a config writer (at least not yet). The logic of writing back a hash which has been created by merging several different data sources, then overriding local settings is way too complex for the initial implementation.
  • the One True Way. instead, it is intended to provide a solid base for handling the basic operations required by all config loaders.  Individual authors can use the style which suits them best.
  • a single file loader. If all you want to do is to load a single Config::General file, then you probably don't need this module. Although, it's a bit like saying "I won't use Getopt::Long because I just need one parameter from the command line... for now"

Config::Loader overview:

    
read 
Read configurations from disk/database using information given from arguments and %ENV. Use modules from the Config:: space to do the dirty work.
merge
Order the loaded and parsed configurations into a single usable hash. Traditionally, yield a flattened hash.
filterFilter and perform substutions.

Each one of the phases could be a different method, allowing people that subclass from Config::Loader to modify these phases using Moose: around, after, before, etc.
 

Things we need to handle / consider

See Proposed functionality for a detailed list of proposed functionality.


Proposed interface

After reading the above, see Proposed interface for the first attempt at a proposed interface


Use cases

If you can think of potential scenarios / use-cases which you would like to handle, please add them to Use cases

2009-05-04 #config-jfdi

A source (or the loader) should be able to supply an insertion point for a configuration hash. For example:

Given a base dir of config/ and a config file of config/database.cnf, the loader should load the contents of config/database.cnf into $config->{database}

IDEA: For each configuration hash that a source supplies, it will be able to assign it a namespace, a weight, and a sibling weight

namespace: The insertion point described above, with depth possibly delimited by "." ( i.e. "database.connection" = $config->{database}->{connection} )

weight: How important a configuration hash is (i.e. _local override)

sibling weight: If a source finds returns many configuration hashes, it should be able to assign a sibling weight, that is, a general ordering. Resolution (importance) would look something like this sort subroutine:

sort { $a->weight <=> $b->weight or $a->sibling_weight <=> $b->sibling_weight } @configuration_hashes