Support rebar3 profile overlay var in relx library

[lrascao]

Relx defines a bunch of builtin overlay vars that are pretty useful (most notably {{release_version}}), it would be pretty cool if it could know about rebar3 metadata as well, for example what profile is being built, sometimes there’s the need to copy build artifacts to the release so a {{profile}} builtin overlay var would be really helpful

[g-andrade]

Is this somewhere on the roadmap?

[ferd]

Not to any degree bigger than any of the other issues here or in the relx repo. There's more work than there's time for all the maintainers involved.

If you're interested in adding support, let us know and we can see how we could provide guidance.

[g-andrade]

I investigated a bit; I had long forgotten that more than one profile can be in use. What do you think would be good semantics for such cases?

For the build directory (rebar_dir:base_dir/1), I see that the different profile names are concatenated (e.g. _build/profile1+profile2). So perhaps the base name of that path could be passed along to relx and exposed as an overlay var?

But it would be strange to call it {{profile}}. {{profiles}} would be a better fit, but then it's not very intuitive how multiple profiles would meld together into a single string (and whether their relative order should matter.)

Alternatively, the new overlay var could be called something along the lines of {{build_dir_name}}, which would be fully precise and correct, but much less discoverable as people will be looking for a profile-thing instead, and might miss what's in front of their eyes.

For now I won't proceed any further as I'm not sure what's the best solution here.

[ferd]

The relative order of profiles does matter in the general case. Merging a+b+c may give a different resulting configuration than c+b+a, specifically in the case where the same values exist in multiple profiles and the later profile dominates. The default profile is also always there but omitted in the path string.

It makes sense to have the values fit what we do for paths, in which case {{profile_string}} might be the best option?

[g-andrade]

[...] in which case {{profile_string}} might be the best option?

Perfect! I'll give a go at a PR with the changes.

[g-andrade]

PR opened in relx in order to make this possible.

[g-andrade]

PR opened.

[g-andrade]

I suppose this issue can now be closed :)