Changing PATH env var doesn't seem to work

[max-sixty]

• Task version: 3.2.2
• Operating System: MacOS & Linux

Firstly thanks a lot for the excellent tool! I've moved lots of hacky shell scripts over to task.

Example Taskfile showing the issue

version: "3"

env:
  PATH: test

tasks:
  path:
    - echo $PATH

The result is my existing path. Switching from PATH to PATH2 shows test as expected. Is this intentional?

[ivotron]

afaik, it is not possible to override environment variables, and this is expected. I asked in #449 whether it'd be possible to add this change in a PR, but the question hasn't been answered. I'd be happy to contribute with this but would like to know first if @andreynering would be open to have a PR with these changes.

[butuzov]

@ivotron Well you can try to implement this and maintain change at least in your fork. As for me will pull this change to mine for sure.

[d3dc]

To me, it seems like the more correct way might be to opt-in to the inheritance.

env:
  PATH: $PATH

I think the closest parallel would be a Dockerfile, where the stacking goes:

• ENV directive
• .env file
• -e flag

I think the interactions for most of this is underspecified. And the "$" in env: actually is equivalent to { sh: }.

[andreynering]

Hi everybody,

Changing the priority order of ENVs is a breaking change and would be unexpected to existing users that rely on it. Currently it's possible to override ENVs with something like env MY_ENV=overriden task foo. This proposal would break that.

Making this change would make ENV work similar to VARS regarding its priority, but would require people to use MY_ENV: '{{default FOO .MY_ENV}}' on all ENV declarations that should be overridable. This could be inconvenient for some and would likely require a release of v4 since it's a breaking change. The same applies to #521.

I would love to hear opinions on what do you think. An alternative would likely be better than a breaking change. Let me know if you have any ideas on how to do that.

---

Regarding the ability to override PATH, as a workaround you could have a variable with the prefix command:

version: '3'

vars:
  PREFIX: env PATH="/some/path:$PATH"

tasks:
  foo:
    cmds:
      - '{{.PREFIX}} my command'
      - '{{.PREFIX}} another command'

Perhaps #204 (comment) would be nice to have this workaround cleaner.

[ghostsquad]

I just found this, and this feels like a pretty big issue. Here's the simplest case:

version: '3'

tasks:
  one:
    env:
      HAM: one
    cmds:
      - echo $HAM


  two:
    cmds:
      - task: one
        env:
          HAM: two

at 13:41:58 ❯ task -t Taskfile.tmp.yml one
task: [one] echo $HAM
one

at 13:42:09 ❯ task -t Taskfile.tmp.yml two
task: [one] echo $HAM
one

I also tried this:

version: '3'

tasks:
  one:
    env:
      HAM: '{{env "HAM" | default "one"}}'
    cmds:
      - echo $HAM


  two:
    cmds:
      - task: one
        env:
          HAM: two

The following DOES work:

version: '3'

tasks:
  one:
    vars:
      HAM: '{{.HAM | default "one"}}'
    env:
      HAM: '{{.HAM}}'
    cmds:
      - echo $HAM


  two:
    cmds:
      - task: one
        vars:
          HAM: two

Which leads me to believe that really vars should be used more liberally than env, and env should always derive from vars, because then you can do this:

version: '3'

vars:
  HAM: '{{env "HAM"}}'

tasks:
...

Which would allow the make behavior of HAM ?= default-value-here

It seems there are many related issues to this as well: #591, #658, #630, #593, #191

[sirenkovladd]

@andreynering

change and would be unexpected to existing users

Have you considered adding an override_env variable in the global scope
which by default will be false (same order as now)
but if true, it will handle replacing existing envs (for example with PATH)

it would not be such a big change to increase the version to v4, but it also allowed to solve this problem

and in the future, simply version v4 will be the default value of true

version: "3"

override_env: true

env:
  PATH: test

tasks:
  path:
    - echo $PATH

[Adirelle]

Have you considered adding an override_env variable in the global scope which by default will be false (same order as now) but if true, it will handle replacing existing envs (for example with PATH)

it would not be such a big change to increase the version to v4, but it also allowed to solve this problem

A per-variable override (force, erase or whatever you see fit) parameter would be fine too. E.g.

version: "3"

override_env: true

env:
  PATH:
    value: test
    override: true

tasks:
  path:
    - echo $PATH