Overlay variable handling is unpractical

[galdor]

In the current state, overlay variables provided by the user in a file are being overriden by variables set by rebar3 and relx. This is the opposite behaviour from what is currently used in any software, where user settings usually override default settings (which makes sense since a user cannot modify default settings).

The problem is compounded by the fact that both rebar3 and relx use lots of variables at top-level without any hierarchy. The worse example is that rebar3 adds a variable for each application, which is associated with its build dir. Therefore adding new dependencies can potentially override existing user variables without any warning.

While I feel that variable overriding should be reversed (relx variables <- rebar3 variables <- overlay_vars variables <- files referenced in the overlay_vars files), I imagine this would cause lots of issues for users.

Another possibility would be to introduce a clear hierarchy, with relx and rebar3 as top levels, which would avoid any potential conflict with user variables. Something similar to the system configuration file of Erlang. Bonus point for using maps instead of lists of pairs. This would also be an uncompatible change.

What do you think about it ?

[tsloughter]

Do you mean variables set in the rebar.config relx section? Or passing a vars file from the cli?

[lrascao]

overlay variables provided by the user in a file are being overriden by variables set by rebar3 and relx

could you provide an example please?

[galdor]

I mean variables set in the overlay_vars file..

[ioolkos]

This is probably not the same issue, but I just noticed that you can't append the same key to a vars.config overlay_vars file.

{key, "a"}.
{key, "b"}.

{{key}} will evalue to "a", not "b". The latter would be useful to cat adaptations for different build profiles.