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.