Rethinking the handling of commands

[lefou]

This is the attempt to persist an interesting conversation on Discord and continue it.

Here is the conversation:

@lefou wrote:

Wouldn't it be nice, to get the task-part of a command without the command-part, and use it like a task?
My typical pattern is currently, to write a task which I then use in a command.

def fooTask(x: X): Task[Y] = T.task {
  ???
}
def foo(x: X): Command[Y] = T.command {
  fooTask(x)
}

@lihaoyi wrote:

i was thinking that we could possibly just treat commands as tasks when used in other targets, e.g. inheriting the working directory rather than using their own (since it has no longer any guarantee of being unique)

I'd like to add, that there are other issue with command, e.g. we don't have a nice compatibility story to evolve existing commands. As Commands need to be resolved via reflection and also support CLI options parsing, we can't rely on Scala def overloading. Hence, it's not easy to evolve a command that accepts args: String* to a more type-safe API.

But we are more free when it comes to Tasks. We could easily add a new tasks accepting more arguments and just forward the command to that task with some mainargs magic applied.

What, if we write all commands as tasks and then only add a small marker to the tasks that should be exposed as a command?

I envision some more binary compatible signature for commands, e.g. Array[String] like we have for def main.

There are multiple ways to realize that. T.command could be just an alias to T.task plus the generation of a synthetic command. Or some other way. I have not really thought it through, especially regarding what's possible with macros in Scala 2.13 vs Scala 3. Hence, I'd like to hear your comments and ideas! Hopefully, we can come up with an design overhault and a final pull request.

[lefou]

Related:

• Commands should support mainargs case classes as parameters #4854 (comment) and following

#4854 (comment)

So, it should work in our normal sources as well. This looks like a good pattern to use in Mill. Maybe we can even drop some boilerplate.

case class MyCmdConfig(name: String)

def cm1(config: MyCmdCOnfig) = Command[MyCmdConfig] {
 println("hello " + config.name
}

// or

def cmd2(args: String*) = Task.Command[MyCmdConfig] { config =>
 println("hello " + config.name)
}

Question is, what is best suited to later change without breakage. From compatibility the String-version is better, as it should even work with a complete different config object when overridden. OTOH, when we want to call it from code, the typed version is better. But we seldomly want to call commands from code.

#4854 (comment)

Ideally, we can get a typed anonymous task suited to be called from code and a untyped command just mapping that task.

def cmdTask(config: MyCmdCOnfig) = Task.Anon[MyCmdConfig] {
 println("hello " + config.name)
}

def cmd(args: String*) = Task.Command(cmdtask)

or

def cmdTask(config: MyCmdCOnfig) = Task.Anon {
 println("hello " + config.name)
}

def cmd(args: String*) = Task.Command[MyCmdConfig](config => cmdtask(config))
// or
def cmd(args: String*) = Task.Command[MyCmdConfig](cmdtask)

[lefou]

Although it would be superior in terms of compatibility, having three definitions (the case class in the companion object, the anon task and the command) is much more boilerplate.

[lihaoyi]

In theory the case class approach and the flat-parameter-list approach should have the same compatibility characteristics. In both cases, evolution can be handled by the @unroll annotation or by manual definition of forwarders

In practice that might not be true right now due to edge cases in the macros and type inference, but it should be possible to make it work