Comparison to other tools

[alexec]

I wonder if anyone has made a comparison between Task and other tools?

taskfile.dev
Kit
Goreman
mprocs
concurrently (NPM)

[trulede]

Actually, Kit looks pretty interesting, but its claim to "Make the dev loop crazy fast" turns me off a little. It's also doing something different than Task (is intended for).

Task itself is not really doing that much. Its directly comparable to Make, or a shell script (i.e. bash). All are equally capable. The real value of Task that is that it provides a method for doing those things which seems more approachable to people who are not so experienced in either Make or Scripting.

Recently I've started thinking that a shell script a curl might be a better alternative ... Task has lots and lots of issues, most of which are lets say "user expectation issues", or a case of not really knowing how to use Task to solve their problem - you do have to read through the doc to understand how to use Task, and even then, you still need experience (of Make or shell) to really take advantage of it ... to understand what is really possible.

If you have a competing tool, I would suggest directly supporting the Task schema with its basic version 3 schema. There are efforts to extend Task further, which will probably only complicate things more, so some users might be interested in a more conservative implementation that recovers some of the grace of Make and shell/bash scripts.

[alexec]

Thank you for the feedback, I think it is time for a new tagline. I'm the author of Kit, and it's getting a revamp (including new tag line!).

My team recently adopted Task on a project (instead of the other options) because of the YAML simplicity, but I made the mistake of doing everything as a task, rather than splitting the workflow into two parts, installing software (e.g. Helm) and running the app (e.g. go run ..

Task is good for running tasks (e.g. Makefile) but not good at running apps because it does not have a concept of a service. Kit has this concepts (as well as native support for Docker and Kubernetes).

The script looks like this:

#!/bin/sh
set -eux

helm version || curl -L https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

mockery --version || go install github.com/vektra/mockery/[email protected]

Each line has a "have I done this already" check, usually printing the version.

This works really well, because if any line of the script fails due to a transient problem (e.g. network issue) you can re-run it and fix the issue, but without repeating work.

[trulede]

The structured nature of the Task schema is really useful, I suspect that is why less experienced users like it - similar things with GitHub actions. Bash scripts, and Make, there is so much history ... that it is really hard to get started ... even if there are good ways to use them. It (the structure) also makes it possible leverage that structural understanding.

Your ideas are quite good. There is something to what you are doing, that's for sure!

[trulede]

I should mention, I also programmatically generate taskfiles, so having a structured Yaml schema makes that particularly easy to do. It's only a small part of what we do, and it does work. We could also generate shell scripts ... I guess. Or use another tool.

Our approach is perhaps not so sofisticated as what you have, never the less take a look if you want:

• Taskfile
• Metadata - used for integration with a custom DSL in VS Code (this will be migrated into the taskfile schema/file soon - pirate action, since task devs are not interested).
• Generated Taskfile - ok, this one was not generated ... its part of a prototype, I will write the code to generate it next week. Here we do some cool versioning things with remote repos and containerised tools.