TomlConfigProvider v0.1.0 TomlConfigProvider View Source

A dead-simple config provider module that plugs into Elixir 1.9 release config. It is meant as a replacement for Toml.Provider, which only works with Distillery.

Link to this section Summary

Functions

Invoked when initializing a config provider.

Loads configuration (typically during system boot).

BEAM configuration expects nested keyword lists, therefore we recursively convert each nested map into keyword lists.

Link to this section Functions

Invoked when initializing a config provider.

A config provider is typically initialized on the machine where the system is assembled and not on the target machine. The c:init/1 callback is useful to verify the arguments given to the provider and prepare the state that will be given to c:load/2.

Furthermore, because the state returned by c:init/1 can be written to text-based config files, it should be restricted only to simple data types, such as integers, strings, atoms, tuples, maps, and lists. Entries such as PIDs, references, and functions cannot be serialized.

Callback implementation for Config.Provider.init/1.

Loads configuration (typically during system boot).

It receives the current config and the state returned by c:init/1. Then you typically read the extra configuration from an external source and merge it into the received config. Merging should be done with Config.Reader.merge/2, as it performs deep merge. It should return the updated config.

Note that c:load/2 is typically invoked very early in the boot process, therefore if you need to use an application in the provider, it is your responsibility to start it.

Callback implementation for Config.Provider.load/2.

BEAM configuration expects nested keyword lists, therefore we recursively convert each nested map into keyword lists.