Activity

1. andreynering

   self-assigned this

   on Feb 20, 2025
2. andreynering

   added a parent issue on Feb 20, 2025

   • Add a interactive TUI powered by Bubbletea #2077
3. task-bot

   added

   state: needs triageWaiting to be triaged by a maintainer.Waiting to be triaged by a maintainer.

   on Feb 20, 2025
4. andreynering

   added

   area: tuiChanges related to TUIChanges related to TUI

   and removed

   state: needs triageWaiting to be triaged by a maintainer.Waiting to be triaged by a maintainer.

   on Feb 20, 2025
5. vmaerten commented on Feb 23, 2025

   

   vmaerten

   on Feb 23, 2025

   Member

   More actions

   Really good idea!
   Do you want to make all of them interactive, or add a new interactive: bool flag?
6. andreynering commented on Feb 23, 2025

   

   andreynering

   on Feb 23, 2025

   MemberAuthor

   More actions

   @vmaerten Not every variable. I think it makes sense that the user chooses which vars make sense to ask. Perhaps something like this:

   tasks:
     my-task:
       cmds:
         - input: MY_VAR
         - echo "Result: {{.MY_VAR}}"

   or

   tasks:
     my-task:
       vars:
         MY_VAR: {input: true}
       cmds:
         - echo "Result: {{.MY_VAR}}"

   👍React with 👍2Reacted by Valentin Maerten and Alexander KIRILOV
7. trulede commented on Mar 3, 2025

   

   trulede

   on Mar 3, 2025

   Contributor

   More actions

   @andreynering we did something similar for a VSCODE extension where text completion for various tasks is driven by some metadata. The metadata approach is useful as UI elements can be developed independent of the Taskfile schema. You know it under #1916 (an example is here).

   Explicitly extending Var to support such interactive use case would also be interesting. But I would suggest something like

   vars:
     FOO:
       prompt: true
       required: false
       default: {{.FOO}}
       desc: BAR
       sh: ... this is the existing schema ... so, same technique/constraints
   

   so that we can develop integrations against that. But I still prefer a metadata object ... since its more flexible. No matter what you put in the schema, it will never cover all use cases.
8. andreynering

   marked Reading input provided by the user #2146 as a duplicate of this issue on Mar 31, 2025
9. timrulebosch commented on May 5, 2025

   

   timrulebosch

   on May 5, 2025

   Last edited by timrulebosch

   More actions

   Could using the template engine work? Where a callback interface, from the template function to the UI, allows the retrieval of additional user input. The default UI would be a simple STDIN based prompt. So for example, chaining some template functions:

   tasks:
     my-task:
       vars:
         MY_VAR: '{{.MY_OTHER_VAR | prompt "foo"}}'  # prompt in "interactive-mode", with default presented to the user
         MY_VAR2: '{{.MY_OTHER_VAR | prompt "bar" | fail "VAR was not set"}}'  # mandatory, must provide
         MY_VAR3: '{{.MY_OTHER_VAR | prompt | default "fubar"}}'  # prompt with no default, then fallback to default for non-interactive case
       cmds:
          - echo "Result: {{.MY_VAR}}"

   In interactive mode, prompt returns the value from the callback, or if "Nil", then the "default" prompt value. Otherwise, in non-interactive-mode, prompt returns the "default" prompt value (so acts like default keyword).
10. sashokbg commented on Aug 14, 2025

    

    sashokbg

    on Aug 14, 2025

    More actions

    Hello I have opened an MR that uses bubbletea to list possible choices for vars:

    #2379
11. vmaerten

    marked "failed: exit status 1" when using "read -p" in a dynamic variable #2518 as a duplicate of this issue on Dec 2, 2025
12. vmaerten

    closed this as completedin #2579on Jan 22, 2026