Add command rebar3 alias

[paulo-ferraz-oliveira]

Closes #2824 (pushed mostly to start the discussion around it).

What's missing?

• tests
• rebar3.org companion update
• a better solution

You can see I work a lot with substrings 😄 Basically, this is because I don't see a way to save what I want in the state, and providers doesn't provide 😄 for a way to save state in the provider either (if, e.g., it had a "meta" or "extra" element we could pass info. around that'd remain internal). I initially was going to use the short_desc field, but there's no accessor there either. Maybe I'll even have to update providers first (depending on guidance) before I move forward.

As is, though, this is functional, albeit "quick and dirty".

[ferd]

What do you think of something like:

    Aliases = rebar_state:get(State, alias, []),
    {{ok, NewState}, Created} = lists:foldl(fun({Alias, Cmds}, {{ok, StateAcc}, CreatedAliases}) ->
                    case validate_provider(Alias, Cmds, State) of
                        true -> {init_alias(Alias, Cmds, StateAcc), [{Alias, Cmds}|CreatedAliases]};
                        false -> {{ok, State}, CreatedAliases}
                    end
                end, {{ok, State}, []}, Aliases),
     {ok, rebar_state:set(NewState, '_created_aliases', Created)}

though maybe written with a bit more readability?
You could then only call rebar_state:get(State, '_created_aliases', []) and get all your data without runtime introspection based on module names.

[paulo-ferraz-oliveira]

Oh, that might be the missing piece. I'll try it out. I was reading through rebar_state but didn't associate opts with the way you're using it 😄

[paulo-ferraz-oliveira]

I'm gonna amend the last commit, since implementation was completely re-done, and I don't think it worth it to keep that bit of history (since it was an experiment).

Thank you, @ferd, you really helped simplify the solution.

Edit: I'm ✅ing "a better solution".

[paulo-ferraz-oliveira]

While looking at the tests, I found e.g.

command() ->
    [{doc, "Runs multiple regular commands as one alias"}].

Is anything picking this up for output, or is it just "internal" documentation? It'd be neat to use elsewhere (been searching for a mechanism like this, that could integrate with CT).

[ferd]

a) it might be nice to namespace the config value ('_rebar_prv_alias_created_aliases') to avoid accidentally trampling over anything

b) that practice with testcasename() is standard within CT, but not the docs field, which we just use as an extra annotation. We may have picked that up from the OTP codebase? Can't recall, but we kept doing it. See https://www.erlang.org/docs/17/apps/common_test/write_test_chapter#info_function -- in fact that one makes the user description go elsewhere by putting it in userdata as a subkey.

[paulo-ferraz-oliveira]

a) 👍
b) good to know, thanks

[paulo-ferraz-oliveira]

I've added a simple test (6c20c5a) that validates the output of rebar3 alias is something like <alias>=... for all configured aliases. Lemme know if that's enough. 👍

I'm ✅ing "tests".

[paulo-ferraz-oliveira]

Documentation for the command has been proposed by tsloughter/rebar3.org#121.

I'm ✅ing "rebar3.org companion update".

[paulo-ferraz-oliveira]

@ferd, I'd had a failure similar to https://github.com/erlang/rebar3/actions/runs/5985193071/job/16237059158?pr=2825#step:5:37 in the past (my rebar3 fork) but am not sure it's related to my changes.

[ferd]

yeah, re-running the tests, that's a weird race.

[ferd]

Nice! Thanks for the contrib, going to merge the doc one too.