Interactive commands
Once parallel targets are implemented (#32, #480), it might get complicated to run interactive application with run in parallel. We probably want some way to indicate, that a command wants to interact with the user (e.g. it reads from STDIN), and ensure, that such a command is run in isolation (no other commands or tasks run in parallel).
What Bazel does is specify that only Targets which are cached and only return an output value can be run in parallel, while Commands which are presumably run for their side effects only run sequentially at the end after all targets have been computed.
We could impose a similar restriction in Mill. Presumably Targets generally should not need to ask for user input, since they're meant to be "pure functions" of their inputs?
Not every command needs that restriction though. E.g. the current JavaModule.Tests.test is implemented as command but runs a non-interactive test framework, which should run in parallel.
To force a non-parallel command, we could invent a new type of command, e.g. T.interactive.
For .test, it might be reasonable just to tell people to use .testCached, since that's already a target and would give parallelism the same as all the other targets.
Not sure if there are other use cases for parallelizable commands that can't be turned into targets; there might be, but we'd have to see what they are before deciding if they're worth supporting
So, you vote for running all command non-parallel and even single threaded? What about runBackground, It's definitely a command we can run in parallel?
IMHO, to make the build as declarative as possible, having a way to tell that a command expects to run interactive is a good thing. It's something we can even detect very early when we run in batch mode (not implemented yet, but e.g. maven has such an option) or simply don't have an input channel.