Request opinions on alternate erlang config formats

Roger Lipscombe roger@REDACTED
Thu Apr 2 10:00:00 CEST 2020


On Wed, 1 Apr 2020 at 22:10, Mark Geib <mark.geib.44@REDACTED> wrote:
> I have looked into cuttlefish, but have reservations regarding
> how it replaces the relx management script for a release,

It doesn't have to, as long as you invoke cuttlefish at some point
before you start the release. You could even do it as part of the
deploy.

We don't use cuttlefish, but we create our config files as part of the
*build* (by layering/merging separate config files), and package them
separately from the main release.

> Also, there will certainly be times where structured
> config is necessary and cuttlefish’s limitations will make that
> difficult.

I found some of our structured config difficult/impossible to map to
cuttlefish schemata.

> 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.

The problem that we found is that you *need* to run the config
transformation (i.e. prep application:get_env) before any configured
applications start. How are you going to configure 'kernel' otherwise?
This means that you *must* transform your input config into sys.config
before the node starts. That's why cuttlefish does it in the startup
script.

> 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.

This depends on who's *actually* going to configure the application.
Everyone wants to simplify the configuration so that "someone else"
can manage it, and then they don't, so that effort was wasted.

Something that validates the config file might be all that you need.
You can start with well-formedness (do the brackets match up?) and
move to schema and semantic checks later.


More information about the erlang-questions mailing list