Idea: Make `--init` more powerful by having Taskfile templates

[andreynering]

From previous discussion in #2010 with @HeCorr. This is an idea for discussion, and we can discard if we think it'd not be worth it.

Our default Taskfile generated from --init is pretty basic. It's basically a skeleton so the user can start adding their own tasks.

In theory we could have some templates for each kind of app: Go, Rust, Ruby on Rails, npm, Yarn, Deno, Docker, etc. IMO they should still be basic, but would help the user by having a starting point.

Implementation wise, we could have a directory in our repository called templates with each template, and have that embed in the binary with go embed. Once --init=rails is called, it'll init with the Rails template, for example (templates/rails/Taskfile.yaml).

Additionally, we could allow the user to override these templates with a directory of his own. Not sure how it'd be more practical, if a CLI flag or an ENV like TASK_EXTRA_TEMPLATES_DIR, but we would merge those with our default templates.

[officel]

Hi!

The other day, go-task was upgraded and the location for the global configuration file changed to XDG Base.
I was hoping that meant the --global taskfile could now be placed in ~/.config/task/Taskfile.yml, but sadly that's not the case.

While pondering this, it occurred to me: maybe I could just place my own base template taskfile in the global tasks directory so it gets loaded?

like this.
https://github.com/officel/config_task/blob/main/Taskfile.yml#L60

If you're waiting for a feature that prepares multiple templates and deploys them during init, I figured it would be faster to just build it into the task itself.

[trulede]

Could we add a template to the taskrc file perhaps? Or even a list of named templates, from which one might be selected.

task --init  # Use the default template from taskrc, if defined, otherwise use the task default.
task --init=foo  # Use the named template.
task --init=  # Lists all named templates from taskrc, same if the named template did not exist, so helpful fail.

[B13rg]

I tried adding a flag --init-template, but it seemed a little long to type and
Creating the various templates should be a separate task.

Add an optional env var like TASK_INIT_FILE to override the template file created with the plain --init command.
Maybe also support setting a directory and use same filename search logic as elsewhere. -> #2814

IF there's effort to create some community Taskfile templates
Add additional flag --template to list/choose templates. As to @trulede's syntax above, it is possible with pflag: no option default values doc

To list available templates it might be easiest to have a few keywords like list for listing available.
Since cli options override env vars an env keyword could be used for selecting the template specified by the env var directly.

[ninlil]

This is a great idea and one I've been thinking about.. but I want to suggest a different approach:

Instead of selecting a single init-file based on variable, language or system, add the option to do something like "task --merge go" which would look in a specified folder and merge those tasks and global settings into the current taskfile.
Any overwrite-protection could be addressed by adding the "--force" argument.

This is because many taskfiles support multiple situations, some compile a language, some build a container, and some do both, or more.

An, yes, I do that merging a yaml is tedious, and almost impossible if it contains whitespaces and comments, so the "merge" would instead be like appending sections at the end of certain top-level elements, and then validating the result before saving it

[trulede]

@ninlil These days you can do that with AI for next to no effort. Really!

[ninlil]

Some environments have limited possibilities to access AI resources, and I find that over time, AI keeps giving me different result for the same query.. and this tools is supposed to have "zero dependencies" and "No extra setup", and having a very repeatable behavior is IMO the most important requirement of a good workflow tool.

So, yes @trulede , AI can easily solve this, but I want a tool with a verified unit-test for a completely deterministic result and so far I've found this tool to be exactly that.

And, if you're interested in my suggestion I could spend some time designing a more detailed technical design