task confirmation

[jdx]

just has a really cool feature to provide confirmation dialogs for a dangerous task:

[confirm("Are you sure you want to delete everything?")]
delete-everything:
  rm -rf *

I'm thinking we could probably go beyond this by leveraging similar features in demand like choosing from different choices: https://github.com/jdx/demand

[roele]

I toyed around a bit with this idea and tried to come up with an extensible way to define these user inputs.

VS Code also has something similar in this regards for tasks, allowing the user to define certain input types which can be used later in the task itself.

So one approach might be to have an inputs property taking an array of input's. Each input has an id with which it can be referenced later, a input_type, a title and a description. Maybe we need specific types for each input_type.

User inputs can then be mapped to prefixed environment variables to be used in the task scripts.

[tasks."confirm"]
inputs = [ 
    { id = "confirm", input_type = "confirm", title = "Do you really want to run this task?" },
]

[tasks."dowhatever"]
run = "echo 'Doing whatever...'"

[tasks."build"]
depends = [ "confirm", "dowhatever" ]
inputs = [
    { id = "success_msg", input_type = "input", title = "Input a build success message" }
]
run = [
  "echo 'Building...'",
  "echo \"Success: $MISE_INPUT_SUCCESS_MSG\";",
  "exit 0;"
]

[tasks."deploy"]
depends = [ "build"]
inputs = [ 
    { id = "target", input_type = "multiselect", title = "Where to deploy to?", options = ["Dev", "Stage", "Prod"]}
]
run = [
  "echo \"Deploying to $MISE_INPUT_TARGET...\";",
  "exit 0;"
]

A working example can be found in an early draft at #2348.

While this works for simple use cases, the major issue i see here is with the nature of parallel (non linear) task execution and interleaving output.

[jdx]

Hmm, so I do like this idea, however I've had plans which might not be written down and are quite vague but essentially I want to tie usage completions and mise tasks together such that you would be able to define a usage spec on a task in order to get inputs. This would be a slightly different use-case but I feel it's similar enough that it conflicts.

What I potentially like about this is maybe "confirmation" could be a high-level thing like that?

Another completely different idea I had was to use tera templates inside of tasks as a way to define inputs, though confirmation doesn't make a lot of sense in that regard.

Perhaps though we're both overthinking this and maybe it could be as simple as "confirm = true"?

[roele]

Yes you might be right about overthinking this. Nevertheless the issues stay the same and demand is not able to deal with the multithreading/interweaving nature of the console output in case of multiple parallel tasks asking for confirmation.

[jdx]

No but I do work around that problem in mise via a mutex. Perhaps that mutex could just go into demand directly? I can’t think of a use-case where you would ever want multiple demand components simultaneously.