Unexpected data race between included var and local var

[dakom]

Description

Given two taskfiles, config.yml and Taskfile.yml:

config.yml

version: "3"

vars:
  FOO: "foo"

Taskfile.yml

version: "3"

includes:
  config:
    taskfile: path/to/config.yml
    flatten: true

tasks:
  foo-1:
    cmds:
      - echo "{{.FOO}}"
  foo-2:
    vars:
      FOO: "{{.REPO_ROOT}}/foo"
    cmds:
      - echo "{{.FOO}}"

foo-1 does not use the imported var from config.yml, while foo-2 does.

This feels like an unexpected data race to me. If it is expected behavior, is the order of overrides like this documented somewhere and I missed it?

Version

3.44.0

Operating system

OSX

Experiments Enabled

No response

Example Taskfile

[andreynering]

Hi @dakom,

I agree that it'd be better if this was deterministic, but for now I simply don't recommend having variables with clashing names.

[dakom]

@andreynering it's not so much about clashing names, as I understand it, but that foo-1 doesn't see the imported var at all

It's as though the order is:

1. Evaluate all vars
2. Evaluate all imports
3. Run commands

Whereas I would have expected it to be:

1. Evaluate all imports
2. Evaluate all vars
3. Run commands

The difference being that vars which I define in the Taskfile, that depend on imports, currently do not use the import

[trulede]

@dakom currently this works as you expect, right?

---
version: "3"

vars:
  FOO: "foo"
---
version: "3"

includes:
  config:
    taskfile: config.yml
    flatten: true

tasks:
  foo-1:
    cmds:
      - echo "{{.FOO}}"
  foo-2:
    vars:
      FOO: "bar"
    cmds:
      - echo "{{.FOO}}"

which produces output:

task: [foo-1] echo "foo"
foo
task: [foo-2] echo "bar"
bar

@vmaerten Perhaps close?

[dakom]

I apologize... my example above doesn't even make sense as REPO_ROOT isn't defined anywhere... must have cut and paste from a project. When I properly create config.yml and Taskfile.yml, I do see the imported var, can't reproduce the bug I was having, so let's assume error on my part :)