feat: added interactive vars using bubbletea

[sashokbg]

This MR adds a new "interactive" option for the vars section. The var section can also be used together with the sh to pre-fill a drop-down list of choices for the user:

Examples:

• Simple use case:

Run: go run ./cmd/task --dir ./testdata/vars/any interactive-simple

  interactive-simple:
    vars:
      MY_VAR:
        prompt: "Enter value for MY_VAR."
    cmds:
      - echo "Var is {{.MY_VAR}}"

Shows:

• Using with sh:

Run go run ./cmd/task --dir ./testdata/vars/any interactive-with-sh

  interactive-with-sh:
    vars:
      MY_VAR:
        sh: printf "choice1\nchoice2\nchoice3"
        prompt: "Please select a value from the list."
    cmds:
      - echo "Var is {{.MY_VAR}}"

Under the hood the second use case uses bubbletea

Any comments and suggestions are appreciated. Thank you !

[trulede]

@sashokbg would it be more succinct to do something like:

tasks:
  interactive:
    vars:
      INPUT_VAR:
        prompt: input
        value: {{.SOMEVAL}}  // this will be the default value
      SELECT_VAR
        prompt: select
        value: "{FOO=true,BAR=false}"  // user presented with list, first value is the default selection, format is whatever bubbletea works with ...
      MULTI_SELECT_VAR
        prompt: multi
        sh: printf "{FOO=ture,BAR=true}" // user is presented with list, the value is again a list with selection modified
    cmds:
      - echo "INPUT_VAR is {{.INPUT_VAR}}"
      - echo "SELECT_VARis {{.SELECT_VAR}}"
      - echo "MULTI_SELECT_VAR is {{.MULTI_SELECT_VAR}}"

Then you could:

task interactive .... and be prompted for each value
or
task --yes interactive ... and have task run with the default prompt values.

[sashokbg]

@sashokbg would it be more succinct to do something like:

tasks:
  interactive:
    vars:
      INPUT_VAR:
        prompt: input
        value: {{.SOMEVAL}}  // this will be the default value
      SELECT_VAR
        prompt: select
        value: "{FOO=true,BAR=false}"  // user presented with list, first value is the default selection, format is whatever bubbletea works with ...
      MULTI_SELECT_VAR
        prompt: multi
        sh: printf "{FOO=ture,BAR=true}" // user is presented with list, the value is again a list with selection modified
    cmds:
      - echo "INPUT_VAR is {{.INPUT_VAR}}"
      - echo "SELECT_VARis {{.SELECT_VAR}}"
      - echo "MULTI_SELECT_VAR is {{.MULTI_SELECT_VAR}}"

Then you could:

task interactive .... and be prompted for each value
or
task --yes interactive ... and have task run with the default prompt values.

Hello @trulede , thank you for your comment and suggestions.

If I understand correctly there are two main things you want to discuss:

1. Different types of inputs - input vs select vs multi-select

Isn't it simpler to just use newline separator ?
This way we don't need to specify "input" vs "select"

About the "multi-select" I am not sure I will have the time to work on that now. Maybe first implement simple inputs / selects and see from there on ?

2. Default values

Regarding the --yes I think it will introduce ambiguity, since --yes is typically used for auto-confirmation and here we use it to kinda skip inputs.
Maybe we need to first work on overriding vars using "--var" syntax as discussed in #850

3. Next steps

In my opinion it would be best to first implement the --var parameter, to allow proper variable overriding and work from there on

Thank you again for your comments

[trulede]

My feedback was more along the lines of utilising/borrowing from the existing schema. For instance:

tasks:
  interactive:
    vars:
      FOO:
        prompt: Enter the name of your chicken 
        value: {{ .FOO | default "foo" }}
      BAR:
        prompt: Select the color of your chicken
        value: {{ .BAR | default 'white' }}
        select: ["blue", "white"]  // infer the prompt style based on this type (i.e. string, list, map)

In this case, borrowing the prompt (and then supporting --yes), which then makes it possible to have more expressive/helpful prompts, and the existing variable overriding mechanism, which with a few exceptions works (e.g. #2288, #2347).

I think there is a broader use case here, extending/intercepting the Task API. In your case, adapting a UI, in my case developing an audit-trail, printing debug info, or producing documentation. It would be easier to simply develop and publish an extension to Task ... but I'm not exactly sure how to do it.

[sashokbg]

Hello, yes the idea of reusing "prompt" looks good.
However referencing .FOO inside the value of FOO looks strange to me. If we have this part just for the default value, maybe we can just add a "default" key like I initially proposed.

Actually I would be tempted to completely remove the defaults and use --var overrides. I opened another PR #2388 that adds this feature.

So the way it would work is that whenever we run a taskfile that has interactive inputs in non-TTY, it would fail and ask you to run it with --var MYVAR=1 etc

[sashokbg]

Hello @trulede I have made a modification by replacing the "interactive" key by "prompt". I also updated the PR description to illustrate it.

Regarding the default values, I will try to use the defaults as described in the doc:

https://taskfile.dev/docs/reference/templating#default-values-and-coalescing