env variable should take precedence

[bluebrown]

Hi, I think the order of importance as listed here: https://taskfile.dev/usage/#variables, doesn't really make a lot of sense.

1. Variables declared in the task definition
2. Variables given while calling a task from another (See Calling another task above)
3. Variables of the included Taskfile (when the task is included)
4. Variables of the inclusion of the Taskfile (when the task is included)
5. Global variables (those declared in the vars: option in the Taskfile)
6. Environment variables

In my opinion, env vars should have the highest priority. Otherwise, it becomes really akward to have default values that someone can overwrite when invoking the cli.

Given I have the below taskfile, I cannot change the value of version from the outside, making it kind of pointless.

version: "3"
env:
  VERSION: dev
tasks:
  default:
    cmd: echo {{.VERSION}}

It would be nice to be able to do VERSION=1 task and have it pick it up. That would feel to me, much more natural and intutive, as I am used to this kind of pattern from other tools.

[JonZeolla]

@bluebrown why not do something like:

$ VERSION='dev' task
task: [default] echo dev
dev

version: "3"
tasks:
  default:
    cmd: echo {{.VERSION}}

[merlindorin]

@bluebrown I agree with you about precedence. Env is always set at the very end for a very particular purpose... they mean to be changed while variables in all levels are set during the design of the task.

As a workaround, I always use default when I want a variable to be overridden using an env.

For example:

version: '3'

vars:
  NAME: '{{.NAME | default "global level name"}}'

tasks:
  demo:
    vars:
       NAME: '{{.NAME | default "task level name"}}'
    cmds:
      - echo "{{.NAME}}"

Usage:

$ task demo
# stdout > taskfile level name

$ NAME=lorem task demo
# stdout >lorem

On my side, it is very useful with including task... but it is very boring and error-prone to set everytime default

[bayeslearnerold]

The document seems very clear about this behavior. {{.NAME |...}} refers to VAR and it will only grab environment variable as a last resort; if no env is set either, then the default takes place.

It took me some time to get this straight.

[diamondburned]

The document seems very clear about this behavior. {{.NAME |...}} refers to VAR and it will only grab environment variable as a last resort; if no env is set either, then the default takes place.

It took me some time to get this straight.

I don't think this necessarily means that it is the desired or common behavior. If backwards compatibility is required, can we add a new key that has the proper behavior? Something like

defaults:
  VERSION: dev

perhaps?

[pd93]

Hi all, there are many open issues related to variables in v3. To help centralise and focus our discussions we have created a new megathread. The env precedence experiment is now stable and there are open tickets linked from the megathread to discuss inheritance and scoping so I'm going to close this issue.