fix: deterministic ordering of required var prompts

[caproven]

Hello! Huge fan of task and while snooping through release notes found the relatively new feature of interactive prompting for required vars courtesy of #2579. The first run I used it for, with 2 required vars, it prompted for the vars backwards based on Taskfile.yml definition order.

I could only reproduce this some of the time, suggesting something like Go map traversal. Here's my Taskfile used for local testing before/after this change:

version: '3'

tasks:
  deps:
    desc: Resolve required vars through dep traversal
    requires:
      vars: [A, B, C, D, E, F]
    cmd: echo "Hello world"

  cmds:
    desc: Resolve required vars through "just-in-time" prompting
    cmds:
      - task: example

Based on #2579 there are 2 effective codepaths for interactive variable prompting to concern ourselves with, aligning with the tasks defined above:

1. Deps
2. Cmds

When running task deps --interactive, there was about a 50% chance on my end that the ordering was completely jumbled. The "cmds" path uses slices internally and I observed no behavioral sequencing issues (task cmds --interactive).

Ordering

The solution presented in this PR is to preserve discovery order of required vars in the "deps" path. This felt the most intuitive to me but I'm open to suggestions. The present non-deterministic order threw me off so I figured it was unintentional.

Regardless of exact ordering, predictability helps with muscle memory (perhaps folks are quickly typing out the same vars in common tasks). I'd say more importantly it preserves semantics intended by the task developer. Take for instance

• [HOST, PORT]
• [IMAGE, TAG]
• Credentials (user/pass)

In each of these cases, being prompted in reverse order would feel off.

• I have read and followed the Contribution Guide

[trulede]

The change seems OK.

However, the rational ... it could be argued that sorting the collated vars is a better solution because there may be several, or even many, dependent tasks ... so any list of required vars is not going to make too much sense.

[caproven]

Fixed issue where Has() wasn't being negated to match original logic, missed this because I mistakenly wasn't testing with actual "deps" in a task definition. Now using:

version: '3'

tasks:
  deps1:
    requires:
      vars: [A, B, C]
    cmd: echo "{{.A}} {{.B}} {{.C}}"

  deps2:
    requires:
      vars: [D, E, F]
    cmd: echo "{{.D}} {{.E}} {{.F}}"

  call-deps:
    deps: [deps1, deps2]
    cmd: echo "Called deps"

The change seems OK.

However, the rational ... it could be argued that sorting the collated vars is a better solution because there may be several, or even many, dependent tasks ... so any list of required vars is not going to make too much sense.

That's a fair point, my Taskfiles are often quite simple so I hadn't thought much on "correctness" when there are many dependent tasks.

Once you have many dependent tasks and/or prompted vars I concur that ordering loses meaning. I'd still argue discovery order is intuitive for simple cases such as a single task. And for complex cases, if semantics fall apart, just having stable order improves things imo.