Is it expected that external environment vars take precedence over env defined in the Taskfile?

[pioio]

I've noticed that external environment variables take precedence those defined in env in the Taskfile?

In other words, the environment vars defined under env keys in Taskfile do not actually define environment variables -- it seems they only define their default values for when those mentioned env vars do not already exist in the environment. If they do exist in system env prior to executing task, the content of env in taskfile is effectively ignored, and the values from the system environment take effect.

I actually really, really like this current behaviour ❤️ . It makes integrating Taskfiles with various external systems (each of which might want its own environment values) much easier.

But, is it expected? I don't see it being documented anywhere. I could open a MR for the docs if it makes sense.

Example of what I meant above.
If I have a task

version: 3
tasks:
  mytask:
    env:
      FOO: bar
    cmds: 
      - echo $FOO

and then run this (I'm setting the env var externally before starting task)
$ FOO=abc task mytask
then the output will be "abc" - the value coming from the external environment takes precedence over value bar defined within the file.

Note that as far as I can see, the above also implies that the only (?) way to override via a Taskfile a possibly already set env var is by setting the desired value in the command directly, e.g.

(...)
cmds:
 - | 
   export FOO=bar
   echo $FOO

Again, I like this behaviour. And I want to confirm it's expected and that it should be documented.

[andreynering]

Hi @pioio,

See discussion in #1038 and #1053.

Different people have different expectation on how some things should behave, so maybe a setting would be the best scenario for flexibility.