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.

[Merott]

I spent hours trying to debug why my tasks were falling back to defaults even for variables defined in my .env file.

Here's what I found…

If you're loading a variable through dotenv at the global level, you can't also provide a default with env at the global level.

Here's an example:

version: '3'

dotenv: ['.env'] # MY_VAR="DOTENV_VALUE"

# global-level env
env:
  MY_VAR: '{{ .MY_VAR | default "FALLBACK_VALUE" }}'

tasks:
  echo-my-var:
    cmds:
      - echo "MY_VAR:" "$MY_VAR"

# > task echo-my-var
# MY_VAR: FALLBACK_VALUE

That will output FALLBACK_VALUE, meaning it doesn't pick up the value of the same name from .env (or at least overrides it.)

But if we move the env setting to a the task-level, it will correctly pick up MY_VAR from .env and output DOTENV_VALUE instead:

version: '3'

dotenv: ['.env'] # MY_VAR="DOTENV_VALUE"

tasks:
  echo-my-var:
    # Task-level env
    env:
      MY_VAR: '{{ .MY_VAR | default "FALLBACK_VALUE" }}'
    cmds:
      - echo "MY_VAR:" "$MY_VAR"

# > task echo-my-var
# MY_VAR: DOTENV_VALUE

The Env Precedence experiment has no bearing on this behaviour.