rebar3 docs for app goals tuple syntax?

[Max Kukartsev]

Could the rebar3 releases page acknowledge the tuple syntax for app goals as in myapp1 below?

{relx, [{release, {<release name>, "0.0.1"},
         [sasl,                        % atom syntax 
          {myapp1, temporary},         % tuple syntax
          {myapp2, "vsn"},             % tuple syntax
          {myapp2, "vsn", temporary},  % tuple syntax
          <app>,
          ...]},
       ]}.

Presently, this syntax appears only on the relx wiki, whereas the rebar3 releases.md states that

<release_name> must be an atom; the same goes for each <app> in the list of applications to include in the release.

If omitting the tuple syntax of app goals was an intentional decision, please disregard this request. 🙂 Otherwise, how would one of proposals below sound?

1. Change the sentence to say that <app> may be an atom or a tuple, and reference the relx wiki for further information.
2. Explain the full syntax for the tuple forms on the rebar3 docs releases page (or a separate, dedicated page).

This may also raise the question of long-term ownership of relx documentation. Presently, the relx wiki contains a mix of valid and obsolete information (e.g., it mentions app goals with constraints, but those were removed in v4.4.0). Playing the long game, it may be helpful to clean up relx wiki (or maybe migrate it to another good-looking statically-generated site like rebar3.org). 😉

Please let me know what you think!

[Fred Hebert]

Yeah I think longer term we'd probably want the relx info to live on rebar3.org. Part of relx 4.0.0 was to drop its standalone mode because most of the use is going to be rebar3-specific (and at some point we'd like to fold it into the other).

Documenting tuple syntax is absolutely reasonable.

[Max Kukartsev]

I can take a first pass at it if you'd like; at least to relax the wording in releases.md about <app> needing to be an atom and give some initial examples akin to the opening message of this issue.

[Fred Hebert]

Yep. If you want it done fastest, you doing it will get the earliest results. My bandwidth is limited these days and chances are I'd work on a messier issue in rebar3 first since those have fewer people able/willing to go dive into the innards.

I'll try to review ASAP as well.