exhuma/config_resolver

Python library to lookup config files in standard locations

config_resolver's Issues

Config version support.

Add an optional constructor parameter "version". If specified the following rules will apply:

• The version is expected to be in section config_resolver with the name config_version
• The version will have the format "major.minor"
• If the major version in the config file differs from the file passed in the constructor an exception is raised.
• If the major version is the same, but the minor version is different, a warning is raised (using the warnings module).

DB Support

Add support to store config values in a database.

Unclear error message!

The warning message complaining about the minor version should contain the major number as well. Just for clarity. The message only appears if the test for the major number passed, so it's implicitly clear, but still confusing! Example message:

group=ept:app=ipbase:Mismatching minor version number. Expected 1, got 0 from filename '/etc/ept/ipbase/app.ini'

Better logging output when overriding the config filename.

The following line is a bit unclear!

INFO:config_resolver:Configuration filename was overridden with foo.ini by an environment vaiable.

Don't raise an exception if major version mismatch in config file.

Currently, a major version mismatch in the config file unconditionally causes an exception. Instead it should log an error and simply skip the file.

This will then only cause an exception if require_load is False.

Unable to install config-resolver >=4.3.6, <5.0

The version.txt is missing in the MANIFEST.in and so the version file is not packaged. When trying to install this particular version I get the following error.

Collecting config-resolver<6.0
  Downloading config_resolver-4.3.6.tar.gz (10 kB)
    ERROR: Command errored out with exit status 1:
     command: /home/users/frank/workspace/platformer/env/bin/python3 -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-wha05sey/config-resolver/setup.py'"'"'; __file__='"'"'/tmp/pip-install-wha05sey/config-resolver/
setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' egg_info --egg-base /tmp/pip-install-wha05sey/config-resolver/pi
p-egg-info
         cwd: /tmp/pip-install-wha05sey/config-resolver/
    Complete output (5 lines):
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/tmp/pip-install-wha05sey/config-resolver/setup.py", line 10, in <module>
        VERSION = open("config_resolver/version.txt").read().strip()
    FileNotFoundError: [Errno 2] No such file or directory: 'config_resolver/version.txt'
    ----------------------------------------
ERROR: Command errored out with exit status 1: python setup.py egg_info Check the logs for full command output.

"Update method" on Config object

it would be interesting to be able to reload the instance of Config when changes have been made in the *.ini file

Include group- and app-name in log messages.

If multiple packages use config_resolver, it would be useful to see both group- and app-name in the logs to better identify the origin of these messages.

No error given for unsecured configs.

If SecuredConfig is used, it should give out a warning if it finds a config file with the wrong permissions.

config.read_string(...) does not work

Following a report from a coworker, the read_string method available on the underlying ConfigParser instance is not working.

Modular config parsing.

Currently, config_resolver's main job is find files, conditionally load them, and load them in a particular order (precedence).

To read the values, it uses SafeConfigParser from the stdlib. For some use-cases, simple .ini files are a bit limiting.

It should be possible to pass in a custom file-parser module, overriding SafeConfigParser. As long as that parser offers a way to read the values needed by config_resolver (currently only the config-file version) it should work.

Additionally, the returned config instance should be of the overridden type. This allows the user to provide a completely customized parser without losing that parser's advanced features.

This will also decouple the file look-up from the config handling.

Leave SafeConfigParser as default if no other parser is specified to keep backwards compatibility.

Allow skipping of configs with mismatching major version

Currently, if a config file is encountered with a mismatching major version number the lookup fails.

It should be made possible to simply skip such files.

Add a license file

Optional exception if no config file was found.

It should be possible to request config files as "mandatory". If this flag is set, it should raise a "file not found" exception if no matching config file was found.

This should be optional, as some applications can very well survive with default settings.

Mismatching minor version numbers give unhelpful error logs

The error log should include the filename:

Mismatching minor version number. Expected '2.1', got '2.2'!

Unix "~/.config" or "~/.group/appname/file.ini"?

Should it use "~/.config" or not?

Remove non-xdg config locations

Drop legacy support for the non-XDG search order. This may break old instances, so this will be scheduled for 5.0

Python 3 support

Does not work with py3k

"Strict" mode. If enabled, raise an exception if an option is not found.

Some options may not be optional. Add a "required" parameter to Config.get. If set to True, and the option does not exist, raise an exception.

WARNING level logging on every use

I'm looking to integrate config_resolver in https://github.com/bluelabsio/records-mover. This is exactly the library I was looking for to provide flexible configuration--thanks for writing it!!

In records-mover, I use Python standard logging. Unfortunately, it appears that every time I use get_config(), I get quite a bit of logging at a very high level (WARNING):

group=bluelabs:app=records_mover:Skipping unreadable file /etc/bluelabs/records_mover/app.ini (File not found)
group=bluelabs:app=records_mover:Skipping unreadable file /etc/xdg/bluelabs/records_mover/app.ini (File not found)
group=bluelabs:app=records_mover:Skipping unreadable file /Users/broz/.config/bluelabs/records_mover/app.ini (File not found)

This appears to be coming from here:

config_resolver/config_resolver/core.py

Line 189 in 7fab236

log.warning('Skipping unreadable file %s (%s)', filename,

Would you accept a PR to change this log level to DEBUG? It seems to me the idea of not having every potential config location full is not a concerning condition that should be warned about.

The workaround I have now is essentially to turn off logging altogether (logging.getLogger('config_resolver').setLevel(logging.ERROR)), but that would also suppress any potential concerning issues at WARNING or useful progress information at INFO being logged by config_resolver.

Ambiguous default filename.

By default, config_resolver looks for a file named app.ini. If multiple applications use config_resolver, this could lead to conflicts when looking of the current working directory. To avoid any conflict, searching the working directory should look into sub folders just like it does in the home folder. Example resolution order:

• /etc/<group>/<app>/app.ini
• ~/.<group>/<app>/app.ini
• ./.<group>/<app>/app.ini

The "secure" flag breaks deployments in OpenShift

The "secure" flag to "get_config" enforces the permissions 0x600 for a config file. But in OpenShift the most secure a file can be is 0x640 because any mounted secrets will be owned by root:<app-user>.

This means that in its current state, config_resolver cannot be used for OpenShift apps.

A backwards compatible change would be to allow to pass in an octal value of the "expected" mode of a file, and use 0x600 if a user passes in True. This way each call could be adapted apropriately.

Initial Update

The bot created this issue to inform you that pyup.io has been set up on this repo.
Once you have closed it, the bot will open pull requests for updates as soon as they are available.

Make sure "meta" information does not conflict when an overriding file is loaded.

Whan a file with version 1.0 is loaded from /etc and later overridden with a more local file with version 2.0 it should throw an exception.