[feature] defered dotenv evaluation

[harlequin]

Is your feature request related to a problem? Please describe.

In the current moon implementation the evaluation of dotenv files happen in a very early stage. After evaluation the task graph is directly created.

This avoids a scenario like , task 1 is creating a valid dotenv file and task2 shall read this and take the env variables for further actions.

Describe the solution you'd like

There are 2 possibilities which can be implemented:-

1. moon will get a new type of tasks configuration

   with this moon can behave like cmake (configuration phase, build phase)
   moon will start with tasks marked as configuration (for example tasks which creates dotenv files) and we would have all the benefits of dependencies and so on
   moon will evaluate the dotenv/action graph as normal (without the configuration task types)
   moon will execute the tasks as normal

2. mark dotenv loading as deferred

   This would implies that the task which declared as deferred dotenv can't be cached
   But would give the possibility of evaluating this during task execution.

[milesj]

This is kind of how it already works. Tasks and the task graph are initially built and the graph is created (build phase). In this phase, tokens are not resolved, and env files are not loaded. This phase is also the one that's cached into .moon/cache.

The next phase is the expand phase, and this happens lazily when a task is first accessed from the task graph. One first access, tokens are resolved, and env files are loaded. This phase can happen at any point in the pipeline, so it's not deterministic.

[harlequin]

I have a use case like this

tasks:

  create:
    command: "Set-Content -Path something.env -Encoding ascii -Value 'FOO=BAR'"

  test:
    command: "Write-Host $env:FOO"    
    deps: 
      - create    
    options:
      cache: false
      envFile: 
         - 'something.env'    

task create produces the envfile and task test consumes it.
When you are executing moon run :test the env variable is emtpy.

[milesj]

Yeah because the task was expanded when building the action graph, which happens before the task is ran. I'm not sure if expanding the task right before running it is possible right now.

[harlequin]

Just make your mind about this and provide me some information about a strategy to implement (deferred, configuration phase and/or even a toolchain api call which can be executed before creating the action graph. as always I can contribute to this