ActiveConfigParser

Overview

The ActiveConfigParser package provides extended handling of .ini files beyond what ConfigParser provides by adding an active syntax to embed operations with options.

For example, a standard .ini file is generally formatted like this:

1[Section 1]
2Foo: Bar
3Baz: Bif
4
5[Section 2]
6Foo: Bar2
7Bif: Baz

These files are used to organize sets of key - value pairs called “options” within groups called “sections”. In the example above there are two sections, “Section 1” and “Section 2”. Each of them contains two options where Section 1 has the keys ‘Foo’ and ‘Baz’ which are assigned the values ‘Bar’ and ‘Bif’, respectively. For more details on .ini files please see the documentation for ConfigParser.

ActiveConfigParser extends the processing capabilities for .ini files by adding an active component of handling of each option. This allows us to merge the processing with the reading of each option. In this model, we treat individual options according to the following syntax:

operation param1 param2 ... 'param with spaces' ... paramN : value

The entries on an option in the key portion are space-separated generally and the first entry can be considered the operation. ActiveConfigParser will attempt to map the detected operation to a handler method and if a matching one is found then it will send the option to that handler for processing. Options that do not map to a handler will be treated as a standard “key:value” pair.

Internally, these handlers methods defined according to a naming convention like handler_<operation>().

ActiveConfigParser only provides one pre-defined operation: use which is formatted as use TARGET: where param1 is the TARGET (there is no value field for this one). The TARGET paramter takes the name of a target section that will be loaded in at this point. This works in the same way a #include would work in C++ and serves to insert the contents or processing of the target section into this location.

The use operation is useful for .ini files for complex systems by allowing developers to create a common section and then have specializations where they can customize options for a given project. For example:

1[COMMON]
2Key C1: Value C1
3Key C2: Value C2
4Key C3: Value C3
5
6[Data 1]
7Key D1: Value D1
8use COMMON
9Key D2: Value D2

In this example, processing section Data 1 via ActiveConfigParser will result in the following options: Key D1: Value D1, Key C1: Value C1, Key C2: Value C2, Key C2: Value C2, Key D2: Value D2.

An alternative way of looking at this is it’s like having a .ini file that is effectively the following where the use operations are replaced with the results of a Depth-First expansion of the linked sections:

 1[COMMON]
 2Key C1: Value C1
 3Key C2: Value C2
 4Key C3: Value C3
 5
 6[Data 1]
 7Key D1: Value D1
 8Key C1: Value C1
 9Key C2: Value C2
10Key C3: Value C3
11Key D2: Value D2

Why Use ActiveConfigParser

An obvious question might by why would we wish to use ActiveConfigParser over the core python package ConfigParser?

The reason for this goes to a DevOps project we were on that needed to generate many configurations of a large multiphysics code with millions of lines of C++ and thousands of configuration combinations.

Many configurations only varied by a few CMake options and we found that standard .ini files would result in a large amount of repetition of the ‘standard’ configurations.

We still liked the .ini file format due to its relative simplicity and ease to edit and understand by stakeholders since they would need to be able to replicate errors when testing uncovered them.

Our solution to this problem was to generate a framework to add additional capabilities to .ini files by allowing the .ini files to be more dynamic throuh the use of operations embedded in properties.

ActiveConfigParser implements just the use operation but the design of the class is for it to be extended and used as a base class for different use-specific configurations. We extended this code in SetProgramOptions to create a bash script generator from these .ini files using the operation param1..N : value model.

Test Coverage

Coverage Report