dirname of current Taskfile

[fj]

I often want to use the directory of where the Taskfile is located as an input to other commands (not the current working directory), but it seems like sprig really locks down access to the filesystem.

Is this possible to do with Task as a first-class idea?

For example, something like:

tasks:
  show-current-dir:
    desc: "show where Task is executing from"
    cmds:
      - echo {{ .TASKFILE_LOCATION }}

Note that this isn't the same as just using $PWD or -d because the working directory might be different; Task should probably provide this as a first-class feature if it doesn't already.

[andreynering]

Hi @fj,

You should actually be fine using pwd if you haven't specified another dir: or your haven't cded in the command.

Otherwise, yeah, I think it makes sense to a have variable with the Taskfile location.

[smyrman]

Actually, could be handy for when Taskfiles are imported as well.

[smyrman]

Example use-case:

root/Taskfile.yaml:

version: "2.X"
includes:
  sub: sub/Tasks.yaml
tasks:
  default:
    cmds:
    - sub:test

root/sub/Tasks.yaml:

version: "2.X"
tasks:
  test:
    dir: "{{.TASKFILE_DIR}}"
    cmds:
    - ./bin/executable

root/sub/bin/executable

#!/bin/sh
echo "Hello World"

[beevelop]

Just stumbled upon this exact issue. I guess a workaround for now is manually setting the dir to the respective folder. The negative side-effect: The Taskfile in the subfolder can no longer be used independently.

[max-sixty]

Is there a way of getting the current working directory when a taskfile in another dir is invoked with -t?

e.g. a variable that would return /home/foo here:

$ pwd

/home/foo

$ task -t /home/foo/bar/Taskfile-baz.yml

# assuming task is `echo {{ .PWD }}`

/home/foo/bar

# how could we get /home/foo ?

[felixlohmeier]

@beevelop:

Just stumbled upon this exact issue. I guess a workaround for now is manually setting the dir to the respective folder.

If directory name and task name are identical, then the following works for included Taskfiles:

dir: '{{splitList ":" .TASK | first}}' # results in the task namespace

The negative side-effect: The Taskfile in the subfolder can no longer be used independently.

To handle this, I use the following default task in the included Taskfile:

  default: # enable standalone execution (running `task` in project directory)
    cmds:
      - DIR="${PWD##*/}:main" && cd .. && task "$DIR"

[SEAPUNK]

I'm curious as to why this isn't the default behavior. If I had a setup like

# Taskfile.yml
version: '3'
includes:
  db: ./db

# db/Taskfile.yml
version: '3'
tasks:
  something: do_something_with ./file.sql

I would expect to be able to do both task db:something and cd db; task something and have them both work. Why doesn't pwd get set per-taskfile? Why do I have to work around this manually?

[andreynering]

@SEAPUNK It seems to be that you just forgot to specify the dir of the Taskfile:

includes:
  db:
    taskfile: ./db
    dir: ./db

To the others: I know that this issue has been opened for a long time (I have been having less than enough time to maintain this), but I'll try to give this some priority.

[SEAPUNK]

@andreynering no, that's what I mean - why should I have to do that? It doesn't feel very intuitive to me (especially considering the quote from the usage page: "By default, tasks will be executed in the directory where the Taskfile is located."), and I end up having to manually set the dir for every taskfile that I import.

[fj]

Thanks for the update, Andrey.

As the person who opened the issue, I do want to acknowledge that as this is a free and open-source project, I don't have any expectation that you have a timetable for fulfilling requests or fixing issues, and that any time you devote at all is appreciated.

best, ~ jf

On Sun, Mar 28, 2021, 09:40 Andrey Nering @.***> wrote:

@SEAPUNK https://github.com/SEAPUNK It seems to be that you just forgot to specify the dir of the Taskfile:

includes: db: taskfile: ./db dir: ./db

To the others: I know that this issue has been opened for a long time (I have been having less than enough time to maintain this), but I'll try to give this some priority.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/go-task/task/issues/215#issuecomment-808898626, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAODVJPOWOYFJKQKC7K423TF4WTVANCNFSM4HYRSAKQ .

[andreynering]

@fj Thanks for the words! 😉

---

@SEAPUNK There's some historical reasons for why it works as is today. Originally, including other taskfiles was a simpler feature, and it was impossible to make it directory aware. When it was added (the ability to set a "dir" for a taskfile import), it was made in a backward compatible way.

Changing it now would break many taskfiles in the wild, because I do know many store common taskfiles in a given directory (I've seen a few .taskfiles/ and similar in the wild) without waiting for these tasks to really run on this folder, but on root.

[SEAPUNK]

@andreynering gotcha, thanks for the explanation. I thought this wasn't something that showed up in the docs, but it looks like I skipped over it.

[rwxd]

Is there a way of getting the current working directory when a taskfile in another dir is invoked with -t?

e.g. a variable that would return /home/foo here:

$ pwd

/home/foo

$ task -t /home/foo/bar/Taskfile-baz.yml

# assuming task is `echo {{ .PWD }}`

/home/foo/bar

# how could we get /home/foo ?

Hi @max-sixty, have you found a solution to the problem?

[max-sixty]

Hi @max-sixty, have you found a solution to the problem?

I found another way of doing what I needed, sorry not to be helpful.

[tylermmorton]

Hi, is it OK to close this issue with the provided workarounds?

[neerfri]

@tylermmorton I think the need for a variable that allows getting the directory of the Taskfile is still open and relevant despite the workarounds

[ssbarnea]

Anything involving PWD would not count as safe, IMHO.

@andreynering Sorry to nag you about this but is there any chance to close this before this bug reaches the 2nd year anniversary? At least if there is a valid workaround we should document it, especially as the need to have such a variable is quite common.

I personally do not care about the effective taskfile location as at this moment I do not use inclusion but I do need a "project_dir" variable, one that would not change even if I call task from a subdirectory.

[ghostsquad]

I agree, task should be able to report directory in which the Taskfile it's operating on is located, though this brings into question, should it always be the parent Taskfile directory, and never the directory of the Taskfiles that are in include?

[andreynering]

@ghostsquad I believe we could have two variables: ROOT_TASKFILE, CURRENT_TASKFILE or something similar.

Sorry for taking so long to work on this, we just have too many opened issues to triage.

This seems to be easy and requested enough that will just put at the top of my priority list.

But if in the meantime, if someone else would like to contribute with this, just let me know.

[ssbarnea]

I was thinking about .PROJECT_DIR and .TASKFILE_DIR, with the mention that the last one implies "current taskfile dir" but I am sure I could live with any variable names, still try to avoid confusing user with a variable name ending in file (TASKFILE) if that is a directory ;)

[andreynering]

Ah, of course, I missed the _DIR suffix, we certainly need it.

My point was about having two variables.

👍 for PROJECT_DIR (alternatively ROOT_DIR) and TASKFILE_DIR

[andreynering]

This was just implemented as part of #857. I plan to do a release still today.