Ability to use the dotenv key inside included Taskfiles

[apgrucza]

Currently the dotenv key cannot be used inside included Taskfiles. Doing so gives the following error:

Included Taskfiles can't have dotenv declarations. Please, move the dotenv declaration to the main Taskfile

Suppose I have the below structure, where the root Taskfile includes the Taskfiles in the subdirectories:

.
├── app
│   └── Taskfile.yaml
├── deployment
│   └── Taskfile.yaml
└── Taskfile.yaml

I find it useful to be able to have the choice to run Task from either:

1. the root directory, e.g. task app:build, or
2. the app subdirectory, e.g. task build

I can't do this and also make use of the dotenv feature. If I place dotenv in the root Taskfile, it will be ignored in case 2. If I place dotenv in the included Taskfile, I get an error in case 1. I'd like dotenv declarations in included files to be processed without error. If the same .env file is referenced in multiple included Taskfiles, this should also not produce an error.

This does raise a question about order of precedence when different .env files are specified across different Taskfiles. Perhaps we could have a rule whereby values in a .env file override values from an included .env file. Or if it's simpler, just return an error if different Taskfiles reference different .env files.

[pd93]

@apgrucza This doesn't solve your problem per se, but you could take a look at the problem/solution in #920 to see if the scenario described there could work for you. You may find that it helps to reduce the number of Taskfiles that you need to include in your project too. However, this probably isn't practical if the Taskfiles in your subdirectories are very specific (i.e. cannot be generalised).

[apgrucza]

Thanks for the suggestion @pd93. In my case the Taskfiles in the subdirectories are indeed very specific and so cannot be generalised.

I could of course move all tasks into the root and have just a single Taskfile, but I prefer the separation of concerns that my current structure provides.

[pd93]

Yep, that's understandable. Just thought I'd see if there was a solution that could work for you in the meantime.

Also, see this related PR and comment where this topic has come up before: https://github.com/go-task/task/pull/904#discussion_r1020762235

[apgrucza]

Regarding this comment from #904:

In a future PR, we could allow dotenv on included Taskfiles, but that would require a refactor so these env would be scoped in the included Taskfile and not merged into the main Taskfile. In short, dotenv would only affect tasks on its own Taskfile and not all tasks. At least that's how I would expect it to work, but this is open to discussion, and we may want to open an issue about this.

I didn’t show it in my example above, but I also have a common Taskfile that’s included from all other Taskfiles. The common Taskfile defines shared variables, some of which need to be based on content from .env files. So scoping dotenv to individual Taskfiles would not work for me.

1030 covers the topic of Taskfile-scoped variables, so I’ve added my thoughts in a comment over there.

[bayeslearner]

I am running into the same organizational question, see below:

.
├── .env
├── .taskfiles
│   ├── folder-a
│   │   └── Taskfile.yml
│   │   └── .env-2
│   └── folder-b
│       └── Taskfile.yml
├── subprj
│   ├── folder-c
│   │   └── Taskfile.yml
│   │   └── .env-3
│   └── folder-d
│       └── Taskfile.yml
└── Taskfile.yml

1. What are the recommended guidelines for including task files? I've slightly altered the example to clarify my question. Consider a directory named .taskfiles, designed to store common task routines for inclusion in other task files. According to this ticket, it seems these task files should not contain environment variable inclusions. Is that interpretation correct?

2. My goal is to execute tasks both from the project's root and within subdirectories, such as sub-prj/folder-c. Moreover, I want to ensure that a task file in folder-c can incorporate common task modules from the .taskfiles directory. This is permissible, right?

3. However, I encounter a problem when attempting to "include" a task file from folder-c into the root task file. Perhaps this action should not be an inclusion but rather a direct invocation?