Inconsistent behaviour of tasks in mix aliases

[stevedomin]

Environment

• Elixir version (elixir -v): 1.3.4
• Operating system: macOS Sierra 10.12.1

Current behavior

I have the following aliases defined:

defp aliases do
    ["test": ["ecto.create --quiet", "ecto.migrate", "test"],
     "test.ci": ["ecto.migrate", "test"],
     "ecto.setup": ["ecto.create", "ecto.migrate", "run priv/repo/seeds.exs"],
     "ecto.reset": ["ecto.drop", "ecto.setup"]]
  end

I'm using the test.ci to run tests using Heroku CI. In that environment I don't need to run ecto.create --quiet because the database is already created for me.

Unfortunately, due to the way aliases work the call to test in my test.ci alias actually calls the test alias and not the original mix test. Having recursive aliases is pretty useful but I feel like it creates inconsistencies: in my example the both the test and test.ci aliases are calling the test task but in one case it's calling the actual task and in the other an alias.

Expected behavior

Running mix test.ci should be the equivalent of running mix ecto.migrate && mix test.

Alternatively there should be a way to say "run this task" and circumvent any alias setup for it. Or by default it should that and then you could have a way of saying, I want to run this alias rather than the task. Something like (the syntax is terrible, it's just to illustrate my proposition):

defp aliases do
    ["test": ["ecto.create --quiet", "ecto.migrate", "test"],
     "test.ci": ["ecto.migrate", "test"],
     "test.distributed": ["prepare.distribution", {:alias, "test"}]]
  end

[josevalim]

It is unlikely this behaviour will change (it is a breaking change) and, as you said, being able to extend existing tasks is quite useful and defaulting to calling aliases is what makes the most sense.

If you want to call the original "test" task, then don't alias it or invoke its run function directly.

I am typically against features that "undo" work, given the best option is to typically never do the work in the first place.

[NobbZ]

Sorry for touching again a closed issue, but have you considered "escaping"
aliases to unalias them, similar to how it is done in various shells?

Lets say, I do have an alias in my shell: alias ls=ls -a, then on every
invocation of ls the switch -a is implied, but when I do instead invoke
\ls in my shell, then the alias is NOT used and ls is called without any
arguments.

Because it is easier to handle in strings and atoms, I do prefer (and
propose) to use the @-sign to escape though. Alternatively a tuple-form
with appropriate tags could be used.

Therefore I will now propose 2 drafts of how to implement this. The first
one is incompatible with the way it is now and will be a breaking change,
it could be postponed to Elixir v2.0 though. The other one would be
"smart", but might introduce even more inconsistencys than we have now.

1. BREAKING: Require to escape explicitely. Even when defining a recursive
   alias. This would mean though that the old syntax as used in the example
   above would lead to an infinite recursion on "test" to resolve the alias.
   In tuple form this would be {:original, "task"}
2. SEMI-SMART: Use original task when defined recursively, as in "test"
   from above, make it impossible to use self-alias. Use aliased version per
   default in any other alias, but make it possible to "unalias" by using
   either the escaped string-form or a tupled version.

And after writing up my SEMI-SMART-suggestion, I can't remember why I
thought it might be more confusing or less consistent than what we have
now. Either I missed some edge-cases I had in mind 5 minutes ago but not
now, or the smart way is the one to go. But because of my current
uncertainity I will suggest both ways for further discussion.

José Valim notifications@github.com schrieb am Fr., 18. Nov. 2016 um
00:52 Uhr:

Closed #5462 #5462.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#5462 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AADmR1WWTVypFo-LROSThCu3DgpBcFFIks5q_OjXgaJpZM4K18h6
.

[stevedomin]

Thanks @josevalim, thought you would say more or less that but it was worth a shot. I was wondering if I missed something obvious in the aliases docs.

[josevalim]

@NobbZ that's a good suggestion but unless more folks show the desire for this feature and they can't have a feasible workaround, I would prefer to keep it simple.

Those issues today can be solved programatically as well, for example:

[test: &test_with_setup/1,
 "test.ci": "ecto.migrate", "test --no-create"]

defp test_with_setup(args) do
  if "--no-create" in args do
    Mix.Task.run "test", List.delete(args, "--no-create")
  else
    Mix.Task.run "ecto.create", "--quiet"
    Mix.Task.run "ecto.migrate"
    Mix.Task.run "test", args
  end
end

So I believe we should prefer that before adding more features.

[stevedomin]

Note for anyone trying to use the example @josevalim kindly gave above:

This line (line 8):
Mix.Task.run "ecto.create", "--quiet"

Should be changed to:
Mix.Task.run "ecto.create", ["--quiet"]