Dynamic variables of included taskfiles evaluated twice

[gkuhlmann-arine]

Before creating an issue, I wanted to discuss if it is intended or necessary behavior.

Summary

When including another taskfile, the dynamic variables of the included taskfile appear to be evaluated twice:

• first, with the "wrong" TASKFILE_DIR value (the parent's)
• second, with the "correct" TASKFILE_DIR value (the child's)

To reproduce

# ./Taskfile.yml

version: '3'

includes:
  child: { dir: child, taskfile: child/Taskfile.yml}

tasks:
  default:
    - task: child:default

# ./child/Taskfile.yml

version: '3'

vars:
  # If you uncomment the following line, running `task` from parent folder will fail
  # ASSERT_CHILD_TASKFILE: { sh: '[[ {{.TASKFILE_DIR}} == *child ]]' }
  MY_TASKFILE_DIR: { sh: 'echo {{.TASKFILE_DIR}}'}

tasks:
  default:
    cmd: '[[ {{.MY_TASKFILE_DIR}} == *child ]]'

Successful case

Without changing any code above:

# from parent folder
task --verbose

Output:

task: dynamic variable: "echo /tmp/parent" result: "/tmp/parent"
task: "default" started
task: dynamic variable: "echo /tmp/parent/child" result: "/tmp/parent/child"
task: "child:default" started
task: [child:default] [[ /tmp/parent/child == *child ]]
task: "child:default" finished
task: "default" finished

Note that MY_TASKFILE_DIR is evaluated first with the "wrong" value and a second time with the "correct" value.

Failing case

Uncomment the ASSERT_CHILD_TASKFILE line in child/Taskfile.yml

# from parent folder
task --verbose

Output:

task: Command "[[ /tmp/parent == *child ]]" failed: exit status 1

Why this is a problem

As the failing case shows, this double-evaluation relies on the first evaluation not failing. However, in a real use case, the script we run for a dynamic variable may only succeed for the "correct" value of TASKFILE_DIR, e.g.

sh: '{{.TASKFILE_DIR}}/my_script.sh'

Discussion

• Is this expected behavior?
• If so, what is the purpose for the first round of evaluation where TASKFILE_DIR is "wrong"?