Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Task-level vars are ignored during 'requires' evaluation #1768

Open
mokeko opened this issue Aug 20, 2024 · 2 comments · May be fixed by #1769
Open

Task-level vars are ignored during 'requires' evaluation #1768

mokeko opened this issue Aug 20, 2024 · 2 comments · May be fixed by #1769
Labels
state: awaiting response Waiting for issue author to respond.

Comments

@mokeko
Copy link

mokeko commented Aug 20, 2024

  • 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.

@task-bot task-bot added the state: needs triage Waiting to be triaged by a maintainer. label Aug 20, 2024
@mokeko mokeko linked a pull request Aug 20, 2024 that will close this issue
@vmaerten
Copy link
Member

What is your use case for this?
Since FILE_LEVEL will always be defined, why would you include it in requires?

@vmaerten vmaerten added state: awaiting response Waiting for issue author to respond. and removed state: needs triage Waiting to be triaged by a maintainer. labels Sep 15, 2024
@NorbertHauriel
Copy link
Contributor

What is your use case for this? Since FILE_LEVEL will always be defined, why would you include it in requires?

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
state: awaiting response Waiting for issue author to respond.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants