Task runner!

[jdx]

rtx is now a task runner! Now you can define common tasks in .rtx.toml like this:

[tasks.build]
run = "cargo build"
sources = ["src/**/*.rs"]
depends = ["lint", "fmt"]

Then you can run it like this: rtx run build. You can manage your scripts either by yourself or by committing them to your project repo to share with others. Of course, rtx launches these with the rtx environment—meaning all the dev tools and env vars will be configured as you'd expect. It's basically the same as running it with rtx exec—though with extra features like watching for changes or launching sub-tasks as dependencies.

There is an alternative way to add scripts by just using bash scripts with special metadata comments (this one needs to live in .rtx/tasks/fmt-check to be picked up by rtx):

#!/usr/bin/env bash
# rtx description="Check the code formatting" 
# rtx depends=["git-clean-working-dir"]
# rtx sources=["src/**/*.rs"]
# rtx env={CARGO_TERM_COLOR = "always"}
set -xeuo pipefail

echo "running cargo fmt"
cargo fmt --all -- --check

This bash script can be launched with rtx run fmt-check—filename is the name of the task. The script does not need to be referenced anywhere else. This makes them quick to author.

I like the bash scripts more personally. They have better syntax highlighting and can be linted with shellcheck—which would be challenging inside of TOML. I like that the bash scripts are a one-step process to create. You don't even need to chmod +x on them—rtx will prompt to make it executable if it isn't already set. I also like that these scripts don't require rtx to run for potential non-rtx users.

I think the downside of bash vs .rtx.toml they're a little less obvious to use with the magic comments and everything. You can mix and match both kinds. bash tasks can depend on toml ones and vice-versa.

Some other features on the task runner:

• rtx will parallelize building depedents (by default)
• rtx will skip building tasks when their sources have not been updated (by default)
• rtx watch -t build will watch for file modifications to re-run the task(s)
• rtx task ls will display a list of available tasks
• rtx task edit edits a task in $EDITOR. This works even if it hasn't been created. I'm probably going to use this a lot anytime I want to start a little script.

Like everything else in rtx, tasks are defined with a merged hierarchy. Meaning you can have an .rtx.toml (or .rtx/tasks scripts) file in your home directory with global actions, then some actions specific to your company in ~/work/.rtx.toml, and project-local actions in ~/work/myproj/.rtx.toml. In case of conflicts the nearest configuration wins. This may make rtx quite unique in the world of task runners. Most/all of them support some form of importing but I don't know of any that does it implicitly like rtx.

Full docs are here: https://github.com/jdx/rtx#experimental-task-runner. It should be ready for you to use but just know that while it's experimental the behavior may change without warning on new releases.

Let me know what you think. Also if you use any other task runner that you like let me know what you like about it.

[mustafa0x]

Woah, awesome, thanks! Simplifying devops is always a huge win.

(I was using poethepoet since poetry doesn't have a task runner.)

[alikefia]

Hello and thank you for mise :)
Is that new feature equivalent to what just can provide ? (asking because I see a justfile in mise repo)
Another one, any plan to improve completions with tasks (nice to borrow from just)

[jdx]

It already has several features missing in just (I think) like parallel execution, watching, and source file dependencies. Completions I am working on, but I'm trying to introduce it alongside the ability to have task inputs.

The way I'm trying to solve inputs/completions is incredibly complex but it should be really good when I can complete it. My hope is that within the next couple of weeks I should have something ready.

[alikefia]

Thanks ! Wanted to make sure I am not missing anything !
Already replacing 'just' and 'direnv' and its layouts with one tool to handle it all

[lpar]

Thanks for the project, but this seems like pretty major scope creep, and I don't understand the use case. I just wanted something to manage installing dev tools and switching between versions of them, like asdf but not a pile of shell scripts.

The direnv functionality fits into that goal, given that dev tools often (unfortunately) require that environment variables be set differently for different versions and projects. But I don't get why a make alternative fits, as programming languages already have their own usual make equivalents (not to mention the shell). Seems to me the less unnecessary functionality in the core mise binary the better, for security reasons.

There's always room for another make replacement, as most of them are horrible, but as you point out, build tools are an incredibly complex problem. Why not a separate build tool?

[lpar]

Yes, but I'm wondering why is the goal to have a dev tool manager that's also a make tool in a single binary? The task runner and other stuff could be a plugin, or another binary that's part of the package. You're planning to support plugins, after all.

[jdx]

plugins would not be capable of doing this. mise is also not simply a "dev tool manager".

[lpar]

Ah, I assumed it could be done as a plugin because that's how asdf does it.

BTW the README "What is it?" section still suggests it's a dev tool manager (plus tasks now), it might be worth putting in a note about what it's planned to be.

[camsteffen]

+1. This makes me a bit hesitant to share this project with co-workers. I'd like to be able to say mise is a simple tool that elegantly solves one problem in your workflow. Installing runtimes and setting up PATH is a thing that devs trip over all the time and mise is a nice solution. A new task runner is a harder sell.

I also think it could be good as a plugin. If the plugin architecture doesn't support it, then that gap could be closed. For instance, git supports having arbitrary git x commands if you have a git-x executable in your PATH.

[jdx]

sorry but this certainly isn't something I'm going to consider removing at this point