Hi,
is there a way for rebar3 to specify command’s default CLI arguments, something like {ct, {args, "--sname test --setookie 123456"}}
or something like that? I found nothing like that in documentation, let me know if I’m missing something.
you could create an alias (Base Config | Rebar3)
in your rebar.config.
e.g.
{alias, [{myct, [{shell, "--sname test --setcookie 123456"}]}]}.
already tried that and it works
wouldn’t that be more clear with overriding command names allowed, e.g. {alias, [{shell, [{shell, "--sname test --setcookie 123456"}]}]}
?
More clear: personally, I do not like “overlays” which obscure the meaning/behaviour of a function.
Maybe this is also the reason why rebar3 ignores aliases with the same name as a builtin function.
Depending on how the overlay is implemented, it might also not be very portable.
If you have a complex test scenario, you could collect it in an .escript or maybe a Makefile.
Part of the reason is that we don’t want people to assume that by aliasing compile
to something else, it will be usable as the alias when building the library as a dependency (where aliases may also be defined differently).
In that way, aliases are a bit like plugins in that they can’t replace any of the core commands and functionality. Plugins can do that by being project_plugins
.
The other reason is technical: All providers (and plugins – they’re the same thing) are created early in the process, and must be registered within a list of acceptable commands. This list is checked for every invocation. To make that work, we end up creating dynamic modules in the shape of a provider that delegate the command to whatever was put in the configuration: rebar3/rebar_prv_alias.erl at 58a6dac54ff2ad76e006f13620727f662e14e716 · erlang/rebar3 · GitHub
We generate abstract code like:
do_func(Cmds) ->
{function, 1, do, 1,
[{clause, 1,
[{var, 1, 'State'}],
[],
[{call, 1,
{remote, 1, {atom, 1, rebar_prv_do}, {atom, 1, do_tasks}},
[make_args(Cmds), {var, 1, 'State'}]}]}]}.
which essentially makes whatever alias you created call rebar_prv_do:do_tasks(...)
. That function in turn is a special one we use as part of the do
provider (when calling rebar3 do [namespace] command [args], ...
). This lets us reuse existing parser code to deal with a single alias that represents a chain of multiple commands consistently, within the system that was already in place and without heavy rearchitecturing of Rebar3 and its whole plugin ecosystem…