Inconsistent behavior when passing vars from CLI in different ways

[orsinium]

• Task version: v3.4.2 (h1:DRATD5qavWC5FqpopJ/JcCelOMakFtGS7CubdZ/FiQY=)
• Operating System: Linux ... 5.4.0-70-generic #78-Ubuntu SMP ... x86_64 x86_64 x86_64 GNU/Linux

The issue description

The documentation implies that passing variables into task as env vars and as arguments has the same effect:

Since some shells don’t support above syntax to set environment variables (Windows) tasks also accepts a similar style when not in the beginning of the command.

However, this is not true. See the example and explanation below.

Example Taskfile showing the issue

version: "3"
vars:
  V: original_v
env:
  EV: "{{.V}}"
  E: original_e

tasks:
  example:
    cmds:
      - echo "env EV is $EV"
      - echo "env E is $E"
      - echo "var V is {{.V}}"
      - echo "var EV is {{.EV}}"
      - echo "var E is {{.E}}"

The example

Running without args:

$ task example -s    
env EV is original_v
env E is original_e
var V is original_v
var EV is 
var E is original_e

This shows the first issue: env is not expanded when used as var ({{.EV}}).

Running with env vars:

$ V=new_v task example -s
env EV is original_v
env E is original_e
var V is original_v
var EV is new_v
var E is original_e

The var was re-defined in env when executed as var ({{.EV}}) but it has the original value for V itself. The documentation says, env vars have the lowest priority, so the latter is expected.

Running with arguments:

task example -s V=new_v
env EV is new_v
env E is original_e
var V is new_v
var EV is 
var E is original_e

Here, using env as var is not expanded as it was in the default execution. However, the explicitly passed value of var is successfully re-defined and substituted when executing the var.

The fix

First of all, executing env vars (env) as regular variables (vars) gives unexpected results. I think it should either match to the value they produce when called as env vars (so $EV and {{.EV}} is always the same), or using them as vars should be explicitly forbidden (since it's not documented anyway).

Secondly, there is a mismatch between passing the var as env var and as a CLI argument. I think the easiest fix is to document the behavior, adding "Variables passed as CLI arguments" before "Global variables" in the list "Task will look for the below".

Another solution for the latter is to prefer "Environment variables" over "Global variables". In that case, the behavior should match. I think it would make more sense since global variables are usually the defaults for the tasks, so explicitly specified variables from the CLI should re-define it. This one is breaking change, though.

[orsinium]

Probably, a duplicate of #436, I'm not sure.

UPD: unlikely, I have the latest release.

[lorenzomar]

I'm thinking out loud without any consideration of breaking changes... 😄

In my opinion a lot of confusion is caused by the overlapping of vars and env. Perhaps a cleaner solution would be to remove the env concept altogether by keeping only the vars.

So "Environment variables" defined by OS or passed inline take precedence over vars defined in the single task which in turn take precedence over global vars.

In this way vars defined in the Taskfile represent default values with a inner hierarchy between task vars and global vars but environment variables could be used to override any default value.

[orsinium]

Related: #1038