avature / confight Goto Github PK

The classifiers field in setup.py is a tuple, and it should be a list:

Warning: 'classifiers' should be a list, got type 'tuple'

pypi/legacy#670

Opt-in support for HCL (HashiCorp Configuration Language) would be nice:

https://github.com/hashicorp/hcl

Version v18.0.0 comes with a few breaking changes:

https://sourceforge.net/p/ruamel-yaml/code/ci/default/tree/README.md

The breaking changes were mitigated in commit 96a1def.

We could now revert it, and change the use of the API in confight.

The file loaders get passed a stream object that was opened by confight.

When overriding a loader for a given format, this might be an issue if the stream is expected to be opened with specific options, or even if the underlying loader implementation doesn’t accept a stream (e.g. only a file path).

Example: tomllib.load() expects the stream to be opened in rb mode, but confight passes a stream opened in r mode to the loader.

The default location for the user configuration should be:

${XDG_CONFIG_HOME:-${HOME}/config}/app/config.toml

This request might not require any effort to fulfil, I haven’t checked the code.

Recursively merging Python dictionaries is an (ever) unsolved problem, on the side of the standard library.

Confight deals with dictionaries, and the community could benefit from its dictionary merging capabilities.

For example:

from confight import merge_dictionaries
merge_dictionaries(defaults, user_config)

Make sure the function is exported and documented.

Aka, "json for humans".

It allows comments, so configuration files could be made way more readable.

https://json5.org/

Docs are specifying support of YAML, but it is not supported (At least in the version that is shipped by the pip by default.).

Here is the code fragment from confight.py

FORMATS = ('toml', 'ini', 'json')
FORMAT_EXTENSIONS = {
    'js': 'json',
    'json': 'json',
    'toml': 'toml',
    'ini': 'ini',
    'cfg': 'ini',
}
FORMAT_LOADERS = {
    'json': lambda *args: json.load(*args, object_pairs_hook=OrderedDict),
    'toml': lambda *args: toml.load(*args, _dict=OrderedDict),
    'ini': load_ini
}

The attempt to parse YAML config results in

ValueError: Unknown format extension 'yaml' for '/etc/<app>/config.yaml'

Nowadays it is very common to have config files in three different places:

1. /usr/share/app. These are the config files that come with the distro package. Different packages can provide config droplets to other packages. They should never be changed by the user, so that package upgrades can work without conflicts.
2. /etc/app. These are the machine-installation-specific config files. They win over 1, so any customization for your local installation goes in here.
3. ~/.config/app. These are user-specific config files. They win over 1 and 2.

The toml library used by confight still doesn’t fully comply with the TOML v1.0.0 specification, and seems abandoned.

Example of problematic shortcoming (several years old) that still isn’t fixed:

• loading of mixed typed arrays
• defined at: https://toml.io/en/v1.0.0#array

Python v3.11 has introduced a library for TOML parsing (read-only): tomllib.

It’s not clear if using tomllib over toml would be a net benefit (trading a set of bugs for another is not ideal).

There’s a good chance that using tomllib by default when Python ≥3.11 is used as an interpreter will be beneficial if not now, at least long-term.

Related to #14.

It would be nice to be able to specify a merging strategy to guide Confight as to what its expected behaviour would be when merging two dictionaries.

Examples include:

• merging lists
• ignoring the right hand value if the left hand value isn’t set (i.e. only update, no upsert)
• replacing the entire left hand dictionary with an existing right hand dictionary (i.e. the default behaviour of {**left, **right})
• matcher objects that dynamically set a strategy, predicated on the current key/dictionary being processed

The list of supported Python versions seems outdated (v2.7 + v3.4 - v3.7).

The codebase should be overhauled to support ideally Python v3.6+, more realistically v3.8+ (to v3.11 would be enough for now).