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

Inconsistent behavior when passing vars from CLI in different ways #483

Open
orsinium opened this issue May 3, 2021 · 3 comments
Open
Labels
area: env Changes related to environment variables. breaking change Changes that are not backward compatible.

Comments

@orsinium
Copy link

orsinium commented May 3, 2021

  • 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 orsinium added the type: bug Something not working as intended. label May 3, 2021
@orsinium
Copy link
Author

orsinium commented May 3, 2021

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

UPD: unlikely, I have the latest release.

@lorenzomar
Copy link

lorenzomar commented May 18, 2021

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.

@pd93 pd93 added area: env Changes related to environment variables. breaking change Changes that are not backward compatible. and removed type: bug Something not working as intended. v4 labels Oct 15, 2022
@orsinium
Copy link
Author

Related: #1038

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: env Changes related to environment variables. breaking change Changes that are not backward compatible.
Projects
None yet
Development

No branches or pull requests

4 participants