/ 
Config-Onion-1.004
River stage two • 2 direct dependents • 89 total dependents
/ Config::Onion

NAME

Config::Onion - Layered configuration, because configs are like ogres

VERSION

version 1.004

SYNOPSIS

my $cfg = Config::Onion->new;
my $cfg = Config::Onion->set_default(db => {name => 'foo', password => 'bar'});
my $cfg = Config::Onion->load('/etc/myapp', './myapp');
my $cfg = Config::Onion->load_glob('./plugins/*');

$cfg->set_default(font => 'Comic Sans');
$cfg->load('config');
$cfg->load_glob('conf.d/myapp*');
$cfg->set_override(font => 'Arial');

my $dbname = $cfg->get->{db}{name};
my $plain_hashref_conf = $cfg->get;
my $dbpassword = $plain_hashref_conf->{db}{password};

DESCRIPTION

All too often, configuration is not a universal or one-time thing, yet most configuration-handling treats it as such. Perhaps you can only load one config file. If you can load more than one, you often have to load all of them at the same time or each is stored completely independently, preventing one from being able to override another. Config::Onion changes that.

Config::Onion stores all configuration settings in four layers: Defaults, Main, Local, and Override. Each layer can be added to as many times as you like. Within each layer, settings which are given multiple times will take the last specified value, while those which are not repeated will remain untouched.

$cfg->set_default(name => 'Arthur Dent', location => 'Earth');
$cfg->set_default(location => 'Magrathea');
# In the Default layer, 'name' is still 'Arthur Dent', but 'location' has
# been changed to 'Magrathea'.

Regardless of the order in which they are set, values in Main will always override values in the Default layer, the Local layer always overrides both Default and Main, and the Override layer overrides all the others.

The design intent for each layer is:

  • Default

    Hardcoded default values to be used when no further configuration is present

  • Main

    Values loaded from standard configuration files shipped with the application

  • Local

    Values loaded from local configuration files which are kept separate to prevent them from being overwritten by application upgrades, etc.

  • Override

    Settings provided at run-time which take precendence over all configuration files, such as settings provided via command line switches

METHODS

new

Returns a new, empty configuration object.

load(@file_stems)

Loads files matching the given stems using Config::Any->load_stems into the Main layer. Also concatenates ".local" to each stem and loads matching files into the Local layer. e.g., $cfg->load('myapp') would load myapp.yml into Main and myapp.local.js into Local. All filename extensions supported by Config::Any are recognized along with their corresponding formats.

load_glob(@globs)

Uses the Perl glob function to expand each parameter into a list of filenames and loads each file using Config::Any. Files whose names contain the string ".local." are loaded into the Local layer. All other files are loaded into the Main layer.

set_default([\%settings,...,] %settings)

set_override([\%settings,...,] %settings)

Imports %settings into the Default or Override layer. Accepts settings both as a plain hash and as hash references, but, if the two are mixed, all hash references must appear at the beginning of the parameter list, before any non-hashref settings.

PROPERTIES

cfg

get

Returns the complete configuration as a hash reference.

default

main

local

override

These properties each return a single layer of the configuration. This is not likely to be useful other than for debugging. For most other purposes, you probably want to use get instead.

prefix_key

If set, enables the Prefix Structures functionality described below when using the load or load_glob methods. The value of prefix_key specifies the name of the key under which the prefix structure may be found.

Default value is undef.

Prefix Structures

If you find that your configuration structure is becoming unwieldy due to deeply-nested structures, you can define a file-specific "prefix structure" and all other settings within that file will be loaded as children of the prefix structure. For example, if your main program uses

$cfg = Config::Onion->new(prefix_key => '_prefix');
$cfg->load("myapp/config");

and myapp/config.yml contains

_prefix:
  foo:
    bar:

baz: 1

then $cfg will contain the configuration

foo:
  bar:
    baz: 1

Note that the top-level prefix_key is removed.

There are some limitations on the prefix structure, in order to keep it sane and deterministic. First, the prefix structure may only contain hashes. Second, each hash must contain exactly one key. Finally, the value associated with the final key must be left undefined.

BUGS AND LIMITATIONS

No bugs have been reported.

Please report any bugs or feature requests at https://github.com/dsheroh/Config-Onion/issues

AUTHOR

Dave Sherohman <dsheroh@cpan.org>

COPYRIGHT AND LICENSE

This software is copyright (c) 2014 by Lund University Library.

This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.