Task-level vars are ignored during 'requires' evaluation
- Task version: 3.38.0
- Operating system: macOS
- Experiments enabled: No
Taskfile.yml
version: '3'
vars:
FILE_LEVEL: 'file'
tasks:
echo:
#requires:
# vars: [FILE_LEVEL, TASK_LEVEL]
vars:
TASK_LEVEL: 'task'
cmds:
- echo '{{.FILE_LEVEL}}, {{.TASK_LEVEL}}'
When running task echo with this file, it succeeds:
$ task echo
task: [echo] echo 'file, task'
file, task
Since both variables are set, uncommenting requires should not change the behavior of task echo. However, it fails with the message: task: Task "echo" cancelled because it is missing required variables: TASK_LEVEL. Task-level variable seems to be ignored during the evaluation of requires.
What is your use case for this?
Since FILE_LEVEL will always be defined, why would you include it in requires?
What is your use case for this? Since
FILE_LEVELwill always be defined, why would you include it inrequires?
A variable, regardless of its scope, is resolved in the task's template. But "requires" does not resolve the scopes the same way. I see these use cases:
- readability: immediately see all variable dependencies, even for tasks that you may not immedately understand.
- explicitness: the scope of the variable is irrelevant, only its name matters, and whether it is provided. If not provided, fail immediately, regardless of its scope. Currently, a removed global variable is silently ignored in all tasks.
- protection from later refactorings: A task variable may be moved to global scope. This should not break the task's "required" IMO, as it did not "lose" any variable dependency. Think of "requires" as saying "I don't care how these dependencies are met now or in the future, unless they are available, and this task can stay functional".
If there is a disagreement, I would like to understand the scope and resolution logic of "requires", so that I do not misuse it. For reference, here is what the schema says:
"A list of variables which should be set if this task is to run, if any of these variables are unset the task will error and not run"
To me, the word "set" and "unset" is ambiguous. I thought a global variable can "set" that variable for the task. Clearly not the case right now.