kynikos / lib.py.configfile Goto Github PK

Allow easily customizing the regular expressions that define the various elements of a configuration file.
For example allow changing the subsection separator, or allow trimming quotes around the value of an option.

Let the user define which mapping class should be used to store the configuration file data (dict, OrderedDict etc.). This would also simplify all the "ordered" and "ignore case" options, since e.g. to ignore the case it would be enough to make a mapping class that saves keys only with lowercase characters.

The current interpolation syntax is very flexible but probably unnecessarily complicated: the characters allowed in section and option names are already very limited by default, so only the interpolation start character could be introduced by a special character. Also, the configured section separator could be used to separate the sections in the path and the option name too. For example:

${section1.section2.option}
${.section1.section2.option}

In this case a leading . should mean a relative path.

${section1/section2/option}
${/section1/section2/option}

In this case a leading / should mean an absolute path.

Note that this change would create a backward incompatibility!

Edit: if using something like:

${section1.section2:option}
${section1/section2:option}

The option name shouldn't need to forbid the section separator, although section names should also forbid the :.

Change reset parameter to remove in main import/export methods (more naturally complementing the overwrite and add parameters).
See also TODOs in source.

Support more data model features.

I was thinking of this config:

site = ArchWiki
cache-dir = ~/.cache/wiki-scripts/

[ArchWiki]
api-url = https://wiki.archlinux.org/api.php
index-url = https://wiki.archlinux.org/index.php

[ArchWiki.statistics]
cookie-file = ${cache-dir$}/ArchWiki.bot.cookie

Unfortunately parsing this with interpolation=True (and inherit_options=True) fails with KeyError: 'cache-dir'...

(Btw. I had to add - to the Section._OPTION regex to support the above keys, which should be solved by #5, but is there a reason why it's not included by default?)

Regular expressions should be compiled only once explicitly, instead of relying on Python's caching.

Support all configparser features, so that this library can replace it (not drop-in though).
For example, optionally support inline comments.

Support multiline values.

When reset-exporting, also the subsections of a no-longer-existing section must be removed.
See also related TODO in source.

Consider using sphinx-apidoc in documentation.

When exporting, automatically introduce added sections and options with comments like "# {These options have|This section has} been added automatically".
Remember that the comment character must be customizable.

To complement #1, it should also be possible to export to a file-like object.

When exporting in reset mode, optionally comment no-longer-existing lines instead of deleting them.

Allow inserting comments programmatically. They should probably be stored in a dedicated dictionary.

Add methods for sorting sections and options, e.g. in alphabetical order.

Allow importing and exporting in shallow mode, i.e. without affecting subsections.

By default, if a key is duplicated in a section, its value is assigned with the cascading rule.
Optionally, instead, interpret this as the definition of a list, with each duplicated key hosting an item:

option = aaa
option = bbb
option = ccc

Alternatively, support interpreting numbered suffixes as list items, for example:

option[1] = aaa
option[2] = bbb
option[3] = ccc

Or distinguish lists from normal keys with a special prefix:

*option = aaa
*option = bbb
*option = ccc

Allow including other configuration files with a special syntax, e.g. #include /etc/config.conf.
Prevend circular inclusions.

Improve the exception classes:

• Compare them with configparser's.
• Derive them from more specific classes than Exception.
• Store more information than just the error message.

Hi,

Quick question:
Can you give an example for changing the _OPTION_SEP from " = " to "="

config = ConfigFile("thefile.cfg")
config["Name"] = "value"
config.export_reset("thefile.cfg",_OPTION_SEP='=')

Allow importing a configuration from a plain multiline string (i.e., if it's a single line, still try to interpret it as a file path).

Move constant settings to a Settings class.

Allow importing Section objects (includes full ConfigFile instances).

Allow easily customizing get_bool's recognized True/False values and the other parameters.

Allow indenting sections and options e.g. relatively to the parent section.
When updating an existing file, the current indentation should be preserved.

I just wrote something like:

cf = configfile.ConfigFile(stream, inherit_options=True)
try:
    return cf(top_level)(subname).get_options()
except KeyError:
    try:
        return cf(top_level).get_options()
    except KeyError:
        return OrderedDict()

I'm dreading the day when I'll need to go one more level deep... At first I thought that inherit_options would allow me to write just return cf(top_level)(subname).get_options() with configfile handling the rest, but it seems that non-existent subsections just don't exist. Would it be safe to let Section.__call__() (optionally) return parent section if the requested one is not found? Is a config file with an only section [foo.bar.baz] even considered valid (i.e. how are the parents of baz handled)?

As an unrelated side note, could you add an example of value interpolation to the documentation? I'm having trouble understanding even the concept...

Add automatic testing and remind to run them before releasing.