nativeconfig 2.1.1

Cross-platform python module to store application config via native subsystems such as Windows Registry or NSUserDefaults.

Developers of cross-platform applications often face problems when they need to interact with the system. Config files are no exception, since every popular OS has its own format and guidelines.

nativeconfig addresses this problem in an elegant and pythonic way:

import os
from nativeconfig import PreferredConfig, StringOption, IntOption

class MyConfig(PreferredConfig):
    CONFIG_VERSION = __version__
    REGISTRY_PATH = r'Software\MyApp'
    JSON_PATH = os.path.expanduser('~/.config/MyApp/config')

    first_name = StringOption('FirstName')
    last_name = StringOption('LastName')
    age = IntOption('Age')

will store config in Registry on Windows, in NSUserDefaults on Mac OS X and in json-formatted file everywhere else.

JSON as universal format

At some point you will need to provide public interface (e.g. CLI or API) to edit config of your application. For this reason there are methods to convert each option individually or whole config into JSON:

class MyConfig(PreferredConfig):
    CONFIG_VERSION = __version__
    REGISTRY_PATH = r'Software\MyApp'
    JSON_PATH = os.path.expanduser('~/.config/MyApp/config')

    first_name = StringOption('FirstName')
    last_name = StringOption('LastName')

MyConfig.get_instance().snapshot()  # will return a JSON dictionary of all options
MyConfig.get_instance().restore_snapshot(user_edited_snapshot)  # will update options with from user-edited JSON

Introspection

It’s always cool when you hack around possible flaws in lib’s code. So you have it: API of BasicConfig and BasicOption is carefully designed to be hackable. In particular, config’s attibutes can be easily inspected via the set of methods grouped under “Introspection” section or by playing with the BasicConfig._ordered_options directly. You didn’t misread, options are already are ordered in order of definition and even subclassing and even overriding!

class MyConfig(PreferredConfig):
    CONFIG_VERSION = __version__
    REGISTRY_PATH = r'Software\MyApp'
    JSON_PATH = os.path.expanduser('~/.config/MyApp/config')

    first_name = StringOption('FirstName')
    last_name = StringOption('LastName')

MyConfig.get_instance().get_value_for_option_name('FirstName')  # will return JSON encoded value of the FirstName option

option = MyConfig.get_instance().option_for_name()
MyConfig.get_instance().get_value_for_option(option)  # same, but by accessing value via attribute

Versioning

The task that every developer is going to face. Fortunately nativeconfig has everything to assist you!

Each config is versioned and default to 1.0. Its version is stored in the config backend under the “ConfigVersion” name which can be altered by modifying the CONFIG_VERSION_OPTION_NAME class variable.

You should override it in custom subclass by defining the CONFIG_VERSION variable. Value that usually makes most sense is the __version__ variable. Each time config is instantiated the migrate method is called. Implementation of the base class simply updates value of the “ConfigVersion” (or whatever you called it) option to the actual value. Reasonably, but insufficiently. Let’s see what we can do:

class MyConfig(PreferredConfig):
    CONFIG_VERSION = __version__
    REGISTRY_PATH = r'Software\MyApp'
    JSON_PATH = os.path.expanduser('~/.config/MyApp/config')

    first_name = StringOption('FirstName')
    last_name = StringOption('LastName')

    def migrate(self, version):
        if version is None:
            # Either called for the very first time OR user's backed is broken because it lacks value of the ConfigVersion option.
            pass

        if version <= <newer version>:
            # Obviously <= will not work for strings. You should use your own comparison function that follows you versioning guidelines.
            pass

        if version <= <newest version>:
            # Version should be checked starting from the oldest to the current so you can gracefully migrate even the oldest user's config.
            # `if` is used instead of `elif` for the same reason: you may need to migrate user's data through multiple versions of the config file.
            pass

        if version <= <most recent version>:
            pass


        super().migrate(version)  # always call base class implementation at the end!

TL;DR three simple rules:

1. Check from the oldest to the newest version

2. User if instead of elif

3. Call super at the end

Error Recovery

When user base is huge, all sorts of weird issues will happen. Unexpected values of options is probably the most common one. And nativeconfig has everything you need to recover from such errors!

Whenever config is unable to deserialize value or if deserialized value is unexpected (e.g. you wanted float bug got a path) the resolve_value method is called. Default implementation logs an error and returns a default. If that’s not sufficient or you have a better idea of how to recover than using default, you should override this method:

class MyConfig(PreferredConfig):
    CONFIG_VERSION = __version__
    REGISTRY_PATH = r'Software\MyApp'
    JSON_PATH = os.path.expanduser('~/.config/MyApp/config')

    first_name = StringOption('FirstName')
    last_name = StringOption('LastName')

    def resolve_value(self, exception, name, raw_value):
        if name == 'FirstName':
            # Restore value from Cloud-stored credentials.
            pass

Pretty basic: you have type of exception (either ValidationError or DeserializationError), name of the option and raw value that either cannot be deserialized or which deserialized representation is invalid.

Debugging

The warn module is used in some places, so you’re advised to debug your app by turning all warnings into errors as described in docs. Various logs are written to the nativeconfig logger. You can increase verbosity by advancing the level.

Testing

To run tests, use the python -m test command.