Allow specifying Environment Variable in env: section to pick up from dotenv or use default

[alewis001]

Currently, if you have:

env:
  ENV: '{{ .ENV | default "default_env" }}'
  VAR_X: '{{ .VAR_X | default "123" }}'

dotenv: ['.env', '.env.{{.ENV}}', '{{.HOME}}/.env']

The ENV variable in this case is picked up from the command line or the value default_env is used otherwise, this is great. However, if VAR_X is set within .env file, then it is not picked up and the value will always be 123 due to the default; it would have to be set on the command line for it to be picked up.

Setting on the command line should take precedence, I think, but otherwise loading from a dotenv file next would be great.

I think there might be a chicken-and-egg situation such that the env vars need to be evaluated in order to select the correct dotenv file but maybe after loading dotenv the env vars defined in the env: section could be re-evaluated?

Thanks for a great tool, finding it really useful so far!

[kundeng]

Hey if you augment your example like this you will see something consistent with the document:

version: '3.3'
env:
  ENV: '{{ .ENV | default "default_env" }}'
  ENV_X: '{{ .ENV_X | default "123" }}'
vars:
  VAR_X: '{{ .VAR_X | default "123" }}'

dotenv: ['.env', '.env.{{.ENV}}', '{{.HOME}}/.env']
tasks:

  default:
    cmds:
    - echo "ENV:" {{ .ENV }}
    - echo "ENV_X:" {{ .ENV_X }}

    - echo "\$VAR_X:" $VAR_X
    - echo "{{"{{"}} .VAR_X {{"}}"}}"  {{.VAR_X}}
    silent: true

.env:

ENV_X = "Hello"
VAR_X = "Hello"

output:

bash-3.2$ task -t test.yml 
ENV: default_env
ENV_X: 123
$VAR_X: Hello
{{ .VAR_X }} Hello

As you can see VAR_X does pick up the .env file defined variables.

There is an experiment in the latest version that alters these orders, which in my opinion is dangerous.