Comparison to other Task Runners? about kit

[alexec]

Kit is not a build tool like the mentioned tools. It is not intended to replace Make or similar.

[agilgur5]

mmm I think that table is a bit incomplete -- I wrote up some comparisons above that I think would be good to include.
In particular, "background tasks" part are particularly relevant and a feature many task runners don't have. tbh, kit could potentially purely occupy the space of tools similar to foreman and just be best-in-class in that area and let other tools do other parts of task running. Although there is ofc overlap between those two functionalities.

Other notes:

• I would definitely consider the markdown runners as declarative; the markdown just makes for very nice readability (it's just a different file format, effectively).
  • Earthly is also declarative, it's a Dockerfile with special syntax
  • Tile has Tiltfile as well
  • Honestly I guess it depends on what you mean by declarative, because by definition task runners are imperative
• k3s isn't really a task runner at all afaik?
• a lot of tools compare to make, so it could be good to include even if you're not comparing build tool functionality (potentially could make that its own column, where you'd throw in things like Bazel etc)

[agilgur5]

Related: argoproj/argo-workflows#11928 (comment).

Pros:

• kit can also handle foreman / goreman-like foreground/background of services/continuous tasks.
  • task does not currently support background tasks: go-task/task#762
    • so you'd have to run goreman as well
  • this does not seem well-documented as a feature though?
• kit's mutex syntax is somewhat unique as a pure string (task and others do not quite have the exact same thing, see argoproj/argo-workflows#11928 (comment))
• kit's port syntax I think makes it wait for a port to be open? I'm not sure how it works actually
• similarly livenessProbe and other auto-restart features for services/background tasks can be convenient
  • task does not currently support auto-restart: go-task/task#1303

Cons:

• mask and xc have nice markdown parsing, so your task file (which most developers will need to read) is a very readable markdown doc
  • task, just, kit etc do not
• task and some others have nice schemas and editor integrations
  • kit has some form(?) of schema too, but usage of it doesn't seem to be documented?
• kit lacks documentation on some core features, as mentioned above
• this could be a pro to some people, but kit's "stringy types" are unintuitive to me given that it's supposed to be in YAML
• kit is a pretty recent project

[alexec]

I wrote Kit because I could not find a tool to do what I want and I knew I could write one easily because I’d written similar code in the pst.

I took a look at your list of tools and Task is most similar. I especially love how the YAML syntax is so similar.

I doesn’t look like it has as sophisticated process management, but maybe they’ll add it?

If Task had all features of Kit, I’d retire Kit.

Kit is not trying to solve the “Makefile is ugly and clunky” problem that other tools are trying to solve, though that is an important problem.

Markdown as code is solving a problem that actually is solved by commenting your build file, not adopting a whole new tool chain.

I find build files are “sticky” and once you’re adopted one, is it hard to change.

[alexec]

One final comment, Kit is actively maintained, but it is feature complete and hasn’t had any bugs for months. You won’t see much activity, and that is a good thing.

[agilgur5]

I doesn’t look like it has as sophisticated process management, but maybe they’ll add it?

Yep that seems to be the main difference and task indeed is lacking on that front as I have learned.
This is also not something that kit advertises or documents too well -- process management is a pretty big feature that many task runners do not seem to have (including make).

If Task had all features of Kit, I’d retire Kit.

I find build files are “sticky” and once you’re adopted one, is it hard to change.

Good to hear 👍 . Yes, this is exactly why I ask this question; no one wants to invest a lot of effort into a specific tool to then have to switch later in time.

Markdown as code is solving a problem that actually is solved by commenting your build file, not adopting a whole new tool chain.

I would disagree that it is solved so simply. There's a reason these kinds of tools are popular (and the ones I listed are far from the only ones). Developer scripts are intended to be read by humans very often and Markdown is a format for humans. Developer scripts are also a great way to get familiar with a repo, so they can serve a similar purpose to a CONTRIBUTING.md or a README.md, with documentation directly in-line.

But that is largely an orthogonal feature in any case; it is not critical but is a nice-to-have. I did mention initially that it is a somewhat different goal.

One final comment, Kit is actively maintained, but it is feature complete and hasn’t had any bugs for months. You won’t see much activity, and that is a good thing.

I don't disagree with this perspective that lack of activity is not bad -- I myself maintain many repos that do not get many issues nowadays, but those normally have a very small scope and have had significant work on them to get to a stable point. Notably, there are many types of issues that only become more obvious after significant usage. (I would also take care to note that "actively maintained" means more than just commits as well).

But there are certainly missing pieces to kit, such as #30 which we've chatted on prior. I also mentioned things like spec integrations and documentation a few times above (both of which task excels in, for example). Other users have mentioned documentation as well. I would not say it is in an "ideal, no more work needed" state as such.

Bugs were mentioned downstream in Workflows; Julie has more experience with the env variable issue. I did say to file an issue here as well so it can be looked into, but it wasn't clear if this project was one of your priorities (Slack thread has more details).

[alexec]

Thank you. Feedback is always valuable. I didn’t know about Task, so that was good to learn about.

It’s was pleasing to see that Workflows users are adopting Codespaces and Nix as I think there’s a paradigm shift going on in OSS as repositories with Codespaces will be much easier to work with.

[agilgur5]

Talked offline a bit about these on CNCF Slack. Writing below for posterity

It’s was pleasing to see that Workflows users are adopting Codespaces and Nix as I think there’s a paradigm shift going on in OSS as repositories with Codespaces will be much easier to work with.

Nix is more of a "dependency management tool", so a bit orthogonal. devenv has some simple foreman-like process management though (see a comparison here)

Re: Codespaces, there does seem to be some issue with it and kit as well, but I'm not sure what specifically yet. See argoproj/argo-workflows#11928 (comment) and argoproj/argo-workflows#11423.
EDIT: I filed #44 on this for posterity.

Kit is not a build tool like the mentioned tools. It is not intended to replace Make or similar.

So notably the issue is titled "Comparison to other Task Runners?", not "build tools".
While make is both a "task runner" and "build tool", I wasn't comparing the build tool functionality here. Earthly is the only tool that compares on that front. As far as I know, make is primarily used as a build tool in the C ecosystem, whereas these alternatives are all in other ecosystems as simplifications of the task runner functionality of make
All the others I mentioned (task, xc, mask, just) are purely task runners. They all compare themselves directly and often explicitly to make, despite only doing the "task runner" portion.

So, to clarify, those are the existing terminology / language and comparisons in the "task runner" space that I was using.

[alexec]