Feature: Allow reading dir and/or entrypoint from env

[therealkevinard]

Are there plans to allow dir/entrypoint from sources other than flag/pwd?
I have early work on this in my fork, but would like to open the conversation before going too far with it.

Use case: task is amazing for monorepos, of course. But monorepos, by nature, may have you at any point in the file tree. It's nice to be able to run repo commands from x directory in the tree. (Eg: trigger a build while you're in path/to/go/service that also builds the dep at path/to/vue/client).

My initial thought was reverse-traversal, looking up the tree until a Taskfile.yml is found, but that carries risk - a task can be intentionally destructive, and that's okay as long as you don't accidentally call it from the wrong place.
Also, it's restrictive. That becomes "the way" to find the root.

Allowing dir args from env

• puts some manual intervention
• allows flexibility: one person may find the dir by recurse-up to the closest taskfile, or may look for the closest .git, or set it as pwd before moving deeper. Whatever works.
• makes a happy CI environment. Most CIs pin a stable root for their stages, which would make it easy to set the env once and reliably call tasks from wherever the script may be.

[therealkevinard]

Another read of the code: a pretty minor adjustment to the pflag setup can read defaults for all args from env.

This should be 100% backwards-compat - it's just adding an alternate default to pflag.

The only concern, I suppose, would be boot time for those who use a bash completion fn. The alternate-default handler is a pretty trivial ternany return, but it would exec several times for each task invocation.

[therealkevinard]

Sidenote: this would play well with #401, assuming it's accepted.

There will undoubtedly be users who want to show all tasks by default.
That PR is written to supplement task -l, so reading -a from env makes this easy.

[andreynering]

Hi @therealkevinard,

Sorry for the 8 months delay. Lot's of issues here, having a hard time to keep up.

If I understood correctly you're proposing that we have envs for --taskfile and --dir? So TASKFILE or TASK_DIR would be alternatives to those flags?

Yeah, I think that's likely simple enough. We already have an env for --color=false now (NO_COLOR). In theory we may add envs for other flags in the future as well, for the ones that make sense of course.

[audunmo]

Were you able to get this to work, @therealkevinard? This would be absolutely amazing