Request opinions on alternate erlang config formats

[Ulf Wiger]

A more elaborate config support can be seen in the Aeternity
blockchain, and the code is available as Open Source, although it
hasn't been cleaned up and refactored to be generic.

The starting point is a JSON-SCHEMA (ex [1]). Writing those is not
exactly fun, but not too bad either.

The API for loading and accessing the config data is in the `aeu_env`
module [2].
Since it supports both JSON and YAML, it relies on `yamerl` and `jsx`
for parsing, and `jesse` for schema-based validation.

Aeternity uses `setup` to control system configuration during startup.
The way this works is that each app can register start hooks with
`setup` using its own application environment, e.g. [3].

The method of checking the config has evolved, so in the Aeternity
source, you can find a number of different approaches, but the more
recent ones can look like this [4]:

get_limit() ->
    {ok, Max} = aeu_env:find_config([ <<"channels">>, <<"max_count">>
] , [ user_config

   , schema_default

   , {value, 1000} ]),
    Max.

That is, you provide a path, where you first grab a user-provided
value, if present, then the schema default, possibly an application
env value, or a hard-coded value.
The config tree is of course hierarchical, so you give the key as a
list of binaries. The schema and user config are cached in ets, and
served either as a tuple tree or a map.

There is also a rebar3 extension (e-)script that checks the user
config from the command line [5].

[1] https://github.com/aeternity/aeternity/blob/master/apps/aeutils/priv/aeternity_config_schema.json
[2] https://github.com/aeternity/aeternity/blob/master/apps/aeutils/src/aeu_env.erl
[3] https://github.com/aeternity/aeternity/blob/master/apps/aecore/src/aecore.app.src#L74
[4] https://github.com/aeternity/aeternity/blob/master/apps/aechannel/src/aesc_limits.erl#L113
[5] https://github.com/aeternity/aeternity/tree/master/apps/check_config

BR,
Ulf W

Den ons 1 apr. 2020 kl 23:01 skrev Mark Geib <mark.geib.44@REDACTED>:
>
> I have been tasked with looking into alternatives to the
> sys.config configuration for erlang releases that are more
> palpable for non-erlangers. In my group there are non-erlang
> developers that suggest property based key=value configs, and
> others that suggest yaml.
>
> I have looked into cuttlefish, but have reservations regarding
> how it replaces the relx management script for a release, I
> use rebar3. Also, there will certainly be times where structured
> config is necessary and cuttlefish’s limitations will make that
> difficult.
>
> I have also looked at yaml parsers, basically transforming the
> yaml config into erlang terms mimicking the sys.conf, and then
> in my application start, I set the environment for the application
> from this. This sort of works in the simple cases, but when you
> need to configure multiple applications, like logger, then it
> gets hard to do something general purpose. And I have not even
> looked into how to handle dependencies that could have yaml
> configs, etc.
>
> So, does anyone use anything other than sys.conf, i.e. the native
> erlang configuration, and if so what do you suggest.??
>
> Also, is this really a problem.?? I have no problem with sys.conf,
> but I write erlang and don’t get squeamish looking at nested braces.
>
> Thanks, and I welcome all opinions.
>
> Mark.