Config Loader

Config::Loader wiki

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

Contents

1 Intended features
2 What Config::Loader is not
3 Config::Loader overview:
4 Things we need to handle / consider
5 Proposed interface
6 Use cases
7 2009-05-04 #config-jfdi

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.
filter	Filter 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

Subpages (3): Proposed functionality - Things we need to handle / consider Proposed interface Use cases