Skip to content

Conversation

@trulede
Copy link
Contributor

@trulede trulede commented Jan 29, 2026

The importing mechanism was/is determining the import directory based on the path of the importing taskfile. This means that the directory of an imported taskfile is not following the expectation of users, and effectively becomes unpredictable as imports are nested.

A imports foo/B imports foo/bar/C (in each case, import dir not specified)
A TASK_DIR = ./
B TASK_DIR = ./
C TASK_DIR = ./foo  *** the logic behind this is cloudy ...

The logic seems to be that, C was imported from B, and therefore C should run in the folder of B (./foo above). However, if B is running in the folder of A (./) then having C run in the folder of B, even though B is running in the folder of A, seems to be wrong. C should run in the folder of B, if B runs in the folder of A, then C should also run in the folder of A.

This PR changes that behaviour, so that it matches the user documentation, and imports taskfiles based on the resolved directory of the importing taskfile. As a result, imports are relative to one another, based on their resolved directories.

Essentially; if taskfile A imports taskfile B then it expects taskfile B to have the same working dir as A, unless the importing mechanism is configured by A (via import dir), in which case taskfile B would have that configured working dir.

fixes #903
fixes #2620

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Inconsistent path resolution when using different includes syntax Working directory of included taskfiles differs depending on called task's location

1 participant