Ability to use a separate tasks file for dev environment

[valxntine]

Having tasks auto-documented by using xc is a strong selling point for the tool, however for projects/repo's with a huge amount of existing tasks, it's daunting to transition if you'd end up with a README that's 4 pages long.

There's currently the -f flag to point to a specific file to be used for running tasks, however I think a QoL addition would be to add a --dev flag that automatically looks at a specific dev tasks file (TASKS.dev.md for example).

Using a flag means it's obvious what's happening and we avoid conflicts with task names, such as if a team has a task dev and a subcommand was added for dev tasks (xc dev task1) there would be conflicts between the task and the subcommand and this could break some existing workflows.

[joerdav]

I'm a fan of this idea, I just want to make sure all the options have been thought about!

The things I'm thinking about when I'm looking at features for xc are:

• Would the running of the task be convenient? (In this case yes, an additional flag isn't too bad)

• Is it a pain to construct it? Nope, it's the same as other xc tasks but in a different file.

• Is it digestable by a human that doesn't have xc installed? Potentially this is where this feature could make an effect. The tasks are no longer referenced from the README.md which is where this documentation would tend to live.

[joerdav]

Thinking about that third point, I wonder if a concept of sub commands could be a thing?

README.md

# Tasks
## dev
Subtasks: TASKS.dev.md
## task-1

echo "hello world"

TASKS.dev.md

# Tasks
## run

go run .

xc dev run

[joerdav]

Or maybe some top level attributes?:

README.md

# Tasks
Subtasks: dev = TASKS.dev.md
## task-1

echo "hello world"

TASKS.dev.md

# Tasks
## run

go run .

[joerdav]

Either way, I think this brings into question how multiple tasks files would interact.

Can you create a task dependancy between tasks? Can a sub task depend on a top level task? Etc etc

[waldyrious]

IMO the subcommands formulation is easier to make sense of than a top-level attribute, and more scalable than a CLI option.