Config...kendMgr(3pm)

✨ NAME ✨

Okay so this is the manual page for Config...kendMgr(3pm) — which, spill the tea, is really Config::Model::BackendMgr — and it does one job and does it gorgeously: it loads configuration nodes on demand. 💅

---

🌸 VERSION 🌸

version 2.166 — she's grown, she's evolved, she's iconic. 👑

---

🦋 SYNOPSIS 🦋

Bestie, here's the whole vibe in code. Want BackendMgr to write your data into a YAML file? Say less:

# Use BackendMgr to write data in Yaml file
# This example requires Config::Model::Backend::Yaml which is now
# shipped outside of Config::Model. Please get it on CPAN
use Config::Model;

# define configuration tree object
my $model = Config::Model->new;
$model->create_config_class(
   name    => "Foo",
   element => [
     'foo' => {
       'value_type' => 'string',
       'type' => 'leaf'
     },
     'bar' => '*foo'
   ]

);

$model->create_config_class(
   name => "MyClass",

   # rw_config spec is used by Config::Model::BackendMgr
   rw_config => {
       backend     => 'yaml',
       config_dir  => '/tmp/',
       file        => 'my_class.yml',
       auto_create => 1,
   },

   element => [
     'foo' => {
       'value_type' => 'string',
       'type' => 'leaf'
     },
     'bar' => '*foo'
     hash_of_nodes => {
         type       => 'hash',     # hash id
         index_type => 'string',
         cargo      => {
             type              => 'node',
             config_class_name => 'Foo'
         },
     },
   ],
);

my $inst = $model->instance( root_class_name => 'MyClass' );

my $root = $inst->config_root;

# put data
my $steps = 'foo=FOO hash_of_nodes:fr foo=bonjour -
  hash_of_nodes:en foo=hello ';
$root->load( steps => $steps );

$inst->write_back;

# now look at file /tmp/my_class.yml

💡 tiny heads up from the original: this example needs Config::Model::Backend::Yaml, which lives outside of Config::Model now. Go grab it on CPAN, bestie.

---

🎀 DESCRIPTION 🎀

So this class is literally the blueprint for telling your model how to load or store config data. That's the whole personality.

With these specs in place, all your configuration info gets read while a node is being created — which is what triggers a backend manager object to spawn, main-character style ✨ — and it gets written back when the write_back method is called on the instance.

That load/store situation can happen through a few different backends:

• Any of the Config::Model::Backend::* classes chilling on your system. Like Config::Model::Backend::Yaml, for example.
• cds_file — that's a Config dump string (cds) in a file. Like, a string describing the content of a configuration tree gets loaded from (or saved into) a text file. This format is defined by this project. Peep "load string syntax" in Config::Model::Loader for the deets.
• perl_file — a Perl data structure (perl) in a file. Config::Model::DumpAsData has the full rundown on the data structure itself. This one is now handled by Config::Model::Backend::PerlFile.

And whenever you need it, "write_back" can be called on the instance (check Config::Model::Instance) to store ALL your configuration info back. everything. no crumbs left behind. 💖

---

🌈 Backend specification 🌈

The backend spec is handed over as an attribute of a Config::Model::Node specification. These attributes are optional — meaning a node with no "rw_config" attribute has to rely on some other node to read or save its data. no solo missions. 🙈

And when it's needed (usually for the root node), the configuration class gets declared with a "rw_config" parameter that spells out the read/write backend configuration.

✨ Parameters available for all backends ✨

Every backend accepts these, zero exceptions:

• config_dir — says where the config directory is. This one's optional since the directory can just be hardcoded in the backend class. If "config_dir" starts with "~", it gets munged so that ~ is replaced by File::HomeDir->my_data. See File::HomeDir for the tea.
• file — says what the config file is called (path not included, okay?). Also optional, because the backend class can hardcode the file name too.

Fun part 👑: when a backend is attached to a node living inside a hash, you can use the &index keyword in the file name. So if "file" is set to &index.conf:

 service    # hash element
   foo      # hash index
     nodeA  # values of nodeA are stored in foo.conf
   bar      # hash index
     nodeB  # values of nodeB are  stored in bar.conf

And same energy with the &element keyword — use it to build the file name too. So with "file" set to &element-&index.conf:

 service    # hash element
   foo      # hash index
     nodeA  # values of nodeA are stored in service.foo.conf
   bar      # hash index
     nodeB  # values of nodeB are  stored in service.bar.conf

• file_mode — lets you set the mode of the file(s) being written. The value can be in literally any form that chmod in Path::Tiny supports. Like:

 file_mode => 0664,
 file_mode => '0664',
 file_mode => 'g+w'

• os_config_dir — gives you an alternate location for the configuration directory depending on the OS (whatever $^O returns, see "PLATFORMS" in perlport). Example, because examples ate:

config_dir => '/etc/ssh',
os_config_dir => { darwin => '/etc' }

• default_layer — optional! Says where to find a global configuration file that specifies default values. OpenSSH uses this to point at a global config (/etc/ssh/ssh_config) that the user's own file overrides. Like:

default_layer => {
   os_config_dir => { 'darwin' => '/etc' },
   config_dir    => '/etc/ssh',
   file          => 'ssh_config'
}

⚠️ And listen — only those 3 parameters above can go inside "default_layer". That's it. Don't try to sneak more in there. 💀

• auto_create — by default, an exception gets thrown if nothing was read successfully. But you can override that whole situation by putting "auto_create => 1" in one of your backend specs. For instance:

 rw_config  => {
     backend => 'IniFile',
     config_dir => '/tmp',
     file  => 'foo.conf',
     auto_create => 1
 },

Setting "auto_create" to 1 is necessary if you wanna create a configuration from scratch. no shortcut, bestie.

• auto_delete — deletes configuration files that contain no data. (default behavior is to leave an empty file there, just vibing)

💜 Config::Model::Backend::* backends 💜

Just drop in the backend name plus whatever parameters that backend's own documentation defines. Easy.

For example:

rw_config => {
    backend     => 'yaml',
    config_dir  => '/tmp/',
    file        => 'my_class.yml',
},

Need more? Check Config::Model::Backend::Yaml for all the details on this one.

🧚 Your own backend 🧚

You can absolutely write your own dedicated backend, bestie. Go off. See How to write your own backend for the how-to.

---

🍓 Test setup 🍓

By default, configuration files get read from the directory named by the "config_dir" parameter you put in the model. And for testing you're allowed to override that "root" directory. slay.

---

⭐ Methods ⭐

support_annotation

Returns 1 if at least the backend supports read and write annotations (aka comments) in the configuration file. 🫶

---

👑 AUTHOR 👑

Dominique Dumont, (ddumont at cpan dot org)

---

🔥 SEE ALSO 🔥

Config::Model, Config::Model::Instance, Config::Model::Node, Config::Model::Dumper

---

💖 AUTHOR 💖

Dominique Dumont

---

🌸 COPYRIGHT AND LICENSE 🌸

This software is Copyright (c) 2005-2022 by Dominique Dumont.

This is free software, licensed under:

The GNU Lesser General Public License, Version 2.1, February 1999

---

okay that's the whole page, you're welcome 💅 this little icon was generated by perl v5.42.3 on 2026-07-23, and it's filed under Config...kendMgr(3pm) — User Contributed Perl Documentation. periodt. ✨🦋🎀