Commands: Support tasks as parameters and make overriding usable

[lefou]

It is currently not possible to depend-on/call commands with parameters, when the parameter value comes from another task.
The typical workaround is to replace the parameter T by a Task[T], but this still required to write an additional method and delegate to it from the command. This PR allows to directly use Task[T] for any supported T, so that no additional boilerplate code is necessary.

Example:

import mill._
import mill.define._

object mod extends Module {

  def extra = T.input {
    "a"
  }

  def command1(arg: Task[String] = T.task()): Command[Unit] = T.command { 
    println(arg())
  }

  def command2(arg: String): Command[Unit] = T.command {
    command1(extra)()
  }

}

Fix #766

We also fix another issue we currently face when users tried to override commands. This never really worked out of the box, as the parameters where not statically known. With the new ability to use tasks, we can finally override command and are still be able to call super.command to reuse the overridden command result.

Here is an example:

import mill._
import mill.define._

trait Mod extends Module {
  def command1(arg: Task[String] = T.task("hello")): Command[String] = T.command {
    val text = arg()
    println(text)
    text
  }
}

object mod extends Mod {
  override def command1(arg: Task[String] = T.task("")): Command[String] = T.command {
    super.command1(T.task("overridden " + arg()))()
  }
}

$ mill showNamed mod.command1 p1
[1/1] showNamed 
[1/1] showNamed > [1/2] mod.command1.overridden.ammonite.$file.build.Mod.command1 
overridden p1
[1/1] showNamed > [2/2] mod.command1 
{
  "mod.command1": "overridden p1"
}

I think this is so useful that we should make it a best practice for commands. We even should review existing commands and refactor them in the next major release cycle (0.11).

[lihaoyi]

This looks really interesting.

The code change is trivial and straightforward, so not much to say there.

At first pass, this lets us call methods taking Task[T] directly from the CLI as T.command, which is a convenience we didn't have before. This might let us do without some trivial forwarders.

As a consequence, it seems we can call the T.command while making some changes to the parameters within a T.task block. This is a bit limited - you can't have code that depends on multiple Tasks in that block - but could still be useful. At a certain level of complexity, you would have to split out a helper method anyway.

Also, it seems that now T.commands are now kind of dynamic, as T.tasks already are: the exact dependencies of the command may include stuff that was passed in. We could already have conditional dependencies in the status quo, e.g. by having code that depends only on the fixed input params before calling the T.command wrapper, so I don't think this will significantly loosen any invariants

[lefou]

Yeah. Most often ask question about overriding commands was in the context of run. Often, users want to hook something before the actual run occurs. Their naive attempts almost always result in execution after super.run()(), as it is a dependency. Now, they can just add their hook as arg-task to ensure, it runs before. Maybe not idiomatic or clean, it solves real world issues.