giampaolo / confix Goto Github PK

...for the most common tasks: istrue, isin, isnotin, isemail etc.

Similarly to: giampaolo/psutil#581

...for ipv4, ipv6 and ipv46

...as in:

@register('foo'):
class conf:
     foo = {'bar': schema(required=True)}

...as in:

schema(validator=[callable1, callable2, ...])

As in:

@register()
class config:
     foo = 1

>>> config['foo']
1
>>> 'foo' in config
True
>>> len(config)
1
>>> config['foo'] = 2
>>> del config['foo']

The order of precedence should be:

env vars -> conf file -> default conf class

...via appveyor.

...because most of the times this is what we want.
The way I imagine this.
With no section:

@register()
class conf:
    foo = 1

With sections:

@register(section='base')
class conf:
    foo = 1

Since this is still super-beta software as a first step it makes sense to remove the current behavior supporting sections.

...since we're dealing with global vars (_conf_map) and we change global class objects at runtime (@register) we better add some locks in order to improve thread safety.

...to ease up testing on multiple python versions

As a way to test against confix version

Returning the global conf as a dict after parse() is called.

...via logging module logger

I have an application where I want to use a default config specified using confix. I want to override this config only when a config file exists, otherwise I want the specified defaults to be used. If you call parse without a path to a valid config file it will error out. Furthermore, if the result of parsing the config file is anything other than a dictionary, then default values with schemas are not initialised, so I don't see a way to achieve this with the current API.

I think this could be handled with a minor refactor like so: rmca@b4debf0

That way at least the caller can handle the case of a non-existent config in a sensible way, while still being able to continue the initialisation of confix and use it for specifying a default config. Alternatively, the parse() function could be reworked to handle this case, but that seems like it would probably require an API change if backwards compatibility is to be maintained. Thoughts?