Perl module to create configuration editor wtih semantic validation
Perl Perl 6
Latest commit 9201574 Oct 12, 2017 @dod38fr dod38fr v2.113
  On-going backend deprecations:
    * using "custom" backend is now fatal
    * warn when more than one backend is declared in a model class.
      This soon will be fatal
    * udpated models (Fstab Multistrap PopCon) to use new rw_config parameter

  Bug fixes:
    * HashId: do not notify when deleting an undef value (Debian #876967)
    * Value: support file test in code eval done by warn_if and similar tests
    * remove confusing "master triggered changed" message
    * really avoid undef warning when homedir is not defined
    * avoid "unordered data" warning when loading one item in an ordered hash

  New features usable with 'cme modify' or in a cme script (used by 'cme run'):
    * add "=.env(...)" instruction to store the content of an environment
      variable in a value
    * add "=.file(...)" instruction to store a file in a value.
      ".file(-)" reads from STDIN.
    * add a User logger category to log messages to user. Direct calls to warn
      will be removed to make test output cleaner

README.md

Config-Model

Configuration schema on steroids.

What is Config-Model project

Config::Model is:

To generate a configuration editor and validator for a project, Config::Model needs:

  • a description of the structure and constraints of a project configuration. (this is called a model, but could also be called a schema)
  • a way to read and write configuration data. This can be provided by built-in read/write backends or by a new read/write backend.

With the elements above, Config::Model generates interactive configuration editors (with integrated help and data validation) and support several kinds of user interface, e.g. graphical, interactive command line. See the list of available user interfaces

Installation

See installation instructions. Perl developers can also build Config::Model from git

Getting started

How does this work ?

Using this project, a typical configuration editor will be made of 3 parts :

  1. The user interface ( cme program and some other optional modules)
  2. The validation engine which is in charge of validating all the configuration information provided by the user. This engine is made of the framework provided by this module and the configuration description (often referred as "configuration model", this could also be known as a schema).
  3. The storage facility that store the configuration information (currently several backends are provided: ini files, perl files)

The important part is the configuration model used by the validation engine. This model can be created or modified with a graphical editor (cme meta edit provided by Config::Model::Itself).

Don't we already have some configuration validation tools ?

You're probably thinking of tools like webmin. Yes, these tools exist and work fine, but they have their set of drawbacks.

Usually, the validation of configuration data is done with a script which performs semantic validation and often ends up being quite complex (e.g. 2500 lines for Debian's xserver-xorg.config script which handles xorg.conf file).

In most cases, the configuration model is expressed in instructions (whatever programming language is used) and interspersed with a lot of processing to handle the actual configuration data.

What's the advantage of this project ?

Config::Model projects provide a way to get a validation engine where the configuration model is completely separated from the actual processing instructions.

A configuration model can be created and modified with the graphical interface provided by "cme meta edit" distributed with Config::Model::Itself. The model is saved in a declarative form (currently, a Perl data structure). Such a model is easier to maintain than a lot of code.

The model specifies:

  • the structure of the configuration data (which can be queried by generic user interfaces)
  • the properties of each element (boundaries check, integer or string, enum like type ...)
  • the default values of parameters (if any)
  • mandatory parameters
  • Warning conditions (and optionally, instructions to fix warnings)
  • on-line help (for each parameter or value of parameter)

So, in the end:

  • maintenance and evolution of the configuration content is easier
  • user will see a common interface for all programs using this project.
  • upgrade of configuration data is easier and sanity check is performed
  • audit of configuration is possible to check what was modified by the user compared to default values

What about the user interface ?

Config::Model interface can be:

All these interfaces are generated from the configuration model.

And configuration model can be created or modified with a graphical user interface ("cme meta edit")

What about configuration data storage ?

Since the syntax of configuration files vary wildly form one program to another, most people who want to use this framework will have to provide a dedicated parser/writer.

Nevertheless, this project provides a writer/parser for some common format: ini style file and perl file.

If you want to discuss Config::Model ?

More information

See