Add special variable for task working directory

[jaynis]

Description

There are various special variables available but none of them reflects the working directory of a respective task. The ones that come closest are:

• USER_WORKING_DIR which contains the directory where task has been called from, but does not honor the -d <dir> command line parameter
  and
• TASK_DIR which merely contains what has been configured under dir: in a task of the Taskfile.yml file and does not even resolve template expressions.

I see two different solutions to this problem:

1. Either change the behavior of USER_WORKING_DIR so that it takes the -d parameter into account, because I see only very little benefit in having a variable which contains the directory where task has been called from when a different working directory has been explicitly set with -d
2. Introduce a new variable such as TASK_WORKING_DIR which contains the desired dir and does not break the current behavior of USER_WORKING_DIR.

The current use case which I have is as follows: I have a root directory containing a Taskfile.yml file and some subdirectories which doesnt have Taskfiles.yml files. I now want to reuse the logic of the Taskfile.yml from the root directory in the subdirectories as described here. This works well if I navigate to a subdirectory and call the respective task from there, however, when I call task from the root directory and specify the subdirectory with the -d parameter it doesnt work as USER_WORKING_DIR still contains the root directory as outlined above.

[jberkenbilt]

I was running into something similar when I came across this. Upon further study, I think -d/--dir only sets the directory in which to start the search for the taskfile. It doesn't change the working directory. This could probably be clearer in the documentation.

Observe. With this Taskfile.yml and an empty subdir:

version: '3'
tasks:
  default:
    cmds:
      - pwd
      - echo {{ .USER_WORKING_DIR }}

% task
task: [default] pwd
/Users/ejb/source/examples/task/bugs/dir
task: [default] echo /Users/ejb/source/examples/task/bugs/dir
/Users/ejb/source/examples/task/bugs/dir

% task --dir subdir
task: [default] pwd
/Users/ejb/source/examples/task/bugs/dir
task: [default] echo /Users/ejb/source/examples/task/bugs/dir
/Users/ejb/source/examples/task/bugs/dir

% (cd subdir; task)
task: [default] pwd
/Users/ejb/source/examples/task/bugs/dir
task: [default] echo /Users/ejb/source/examples/task/bugs/dir/subdir
/Users/ejb/source/examples/task/bugs/dir/subdir

Now create subdir/Task.yml:

version: '3'
tasks:
  default:
    cmds:
      - echo in subdir
      - pwd
      - echo {{ .USER_WORKING_DIR }}

Now:

% task --dir subdir
task: [default] echo in subdir
in subdir
task: [default] pwd
/Users/ejb/source/examples/task/bugs/dir/subdir
task: [default] echo /Users/ejb/source/examples/task/bugs/dir
/Users/ejb/source/examples/task/bugs/dir

So it seems that --dir is not setting the working directory, but is setting the directory from which task starts the search for Taskfile.yaml.

[jberkenbilt]

In case I'm right, see #2123.

[jaynis]

Hi @jberkenbilt . Thank you for your detailed response. I think you are indeed right, but I dont see how your observation is different from mine. Maybe it is just wording. So my understanding is was/is:

• USER_WORKING_DIR contains the working directory in the sense of the directory where task has been called from
• --dir sets the directory where task starts looking for Taskfile.yml files

All I wanted to achieve is to have a special variable which contains the path which has been set with --dir so that I can use this to specify the task directory with dir: in my task file. As already stated in my initial post, this can be achieved already now by navigating to that directory first and executing task from there, but I would like to have a way to do this without having to use a tiny script such as (cd subdir; task).
I called the new variable to contain that directory TASK_WORKING_DIR because it is the directory task is/starts working on, in contrast to USER_WORKING_DIR, the directory task has been called from by the user. I am also open to renaming it to something more verbose like TASK_DIR_PARAM but this could cause confusion with the already existing TASK_DIR variable.

[jberkenbilt]

Oh, @jaynis, I see. I guess there are really three different things.

Suppose you have this Taskfile:

version: 3
tasks:
  default:
    cmds:
      - echo pwd = $(pwd)
      - echo USER_WORKING_DIR = {{ .USER_WORKING_DIR }}
      - echo TASK_DIR = {{ .TASK_DIR }}

and this directory structure:

/tmp/z
     └── a/
         └── b/
             ├── Taskfile.yml
             ├── c/
             └── d/

• Where you were when you ran task
• The directory where you started the search for Taskfile (specified by --dir, currently not available)
• The directory where the Taskfile actually was

If you are in /tmp/z/a/b/c and run task -d ../d, there's no way to know about ../d's path. You get this:

task: [default] echo pwd = $(pwd)
pwd = /tmp/z/a/b
task: [default] echo USER_WORKING_DIR = /tmp/z/a/b/c
USER_WORKING_DIR = /tmp/z/a/b/c
task: [default] echo TASK_DIR = /tmp/z/a/b
TASK_DIR = /tmp/z/a/b

Your first comment says you don't see much of a use case for knowing where task was started from when run with -d, but I think the use case is very similar to your use case. The use case is that you have a collection of utility task files, and you are running them somewhere unrelated. Like maybe you have a Taskfile somewhere to help you build docker images. You might be in /projects/something/docker/ and run task -d /projects/taskfiles/docker-util.

I still think the problem is that -d doesn't actually change the working directory. I could see that it would be useful to know the path of where -d actually pointed to it, which might be different from either the current working directory or the directory where the task was found.

Anyway, I don't think what I'm saying contradicts what you're saying; I'm just adding the nuance that I think, regardless of whether the feature you want is there, the documentation for --dir is misleading.

Anyway, I'm new here -- I just started playing with taskfile today and don't have any connection with the project. :-)

[jaynis]

Well, as you must have noticed in your PR, strictly speaking the --dir parameter does not even state that it sets the working directory, but merely the directory of execution. If you interpret execution with directory where taskfile starts executing Taskfile.yaml files, then I would even say the documentation is kind of okayish even now. But you can of course very easily interpret this differently, therefore I am not saying that your PR doesnt make sense. 😃

I agree that having a variable which contains the directory from which task has been called from (USER_WORKING_DIR) makes sense in any case. Your example demonstrates this very well. When I created this issue I only had this use case in mind.