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
init(path) View Source
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
.
load(config, path) View Source
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
.
transform(val) View Source
BEAM configuration expects nested keyword lists, therefore we recursively convert each nested map into keyword lists.