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.)

[BoastfulScull]

Thanks for mise!!

[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?

[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

[hverlin]

There is another project called https://moonrepo.dev/ which has a tool to manage dev tools (proto) and another one to manage tasks (moon). They feel quite similar in many ways.

[mgielda]

I think many people will applaud the task runner capabilities (even though some will complain), since this is something you need soooooo often, and end up with a bunch of bash scripts in the end (or worse, package.json "scripts"). Using mise for this would be nice!

[syhol]

I like how this makes it more viable to use mise without shell integration 🙌

[jdx]

that's one of the reasons I built it!

[michael-skovik]

Thanks a lot for the awesome project, mise tasks are really looking interesting.
However, after using it for a few days now, I have stumbled upon a use case which I could not find the possibility for in the documentation or the source code. Is it possible to run tasks from the same directory they were sourced from, while located in a sub directory? Maybe using dir = ?

E.g say that my .mise.toml file is located in /outer/.mise.toml with task:

[tasks.foo]
run = "echo $(pwd)"
#dir = "???"

and I invoke $ mise r foo in directory /outer/inner/. Without dir it would simply output /outer/inner/ but in my use case I would want it to output /outer/, so that no matter how deep I am in the directory tree, it will always execute from the task source level.
I saw that there were some .mise.toml examples using dir = {{CWD}}. Are there other keywords or macros similar to that one that could be useful in this scenario? Of course, hard coding the path to the directory is possible, but not it is not what I am looking for.

This would be really useful for tasks that always need to be executed on a specific level in a directory tree.
Thanks!

[airtonix]

[tasks.foo]
run = "cd $root; echo $(pwd)"

I've been doing something horrible like this.

I thought setting dir would work, but that seems to be relaitve too and thus useless.

[michael-skovik]

@airtonix While scanning through the documentation for mise again, it seems to be possible to do

[tasks.foo]
run = "echo $(pwd)"
dir = "{{config_root}}"

Using templates does require you to "trust" the config though.

[sandstrom]

Feedback

We have a set of tasks like this:

[tasks."setup:libraries"]
depends = [
  "setup:dependencies",
  "setup:libraries:*", # WORKAROUND
]

[tasks."setup:libraries:cocoapods"]
depends = ["setup:dependencies:ios"]
run = ["gem install cocoapods"]

[tasks."setup:libraries:capacitor"]
depends = [
  "setup:dependencies:ios",
  "setup:dependencies:android",
  "setup:libraries:cocoapods",
]

run = ["npm install capacitor"]

But it feels a bit wrong to mix task running (running sub-tasks) with dependencies.

I'd prefer if we could specify it like this:

[tasks."setup:libraries"]
depends = ["setup:dependencies"]
run_tasks = ["setup:libraries:*"] # SUGGESTION

[tasks."setup:libraries:cocoapods"]
depends = ["setup:dependencies:ios"]
run = ["gem install cocoapods"]

[tasks."setup:libraries:capacitor"]
depends = [
  "setup:dependencies:ios",
  "setup:dependencies:android",
  "setup:libraries:cocoapods",
]

run = ["npm install capacitor"]

[Heus-Sueh]

I realized that some tasks will be used frequently and written manually every time when creating a Python project (or any other language). An idea that could reduce the need to write common tasks every time is a way to copy task "templates" defined in ~/.config/mise/templates and copy them to the current project or "inherit" them in some way. For example, every Python project, depending on the user, uses ruff and pytest and it is necessary to write this every time. If there was a way to define this only once and ask mise to get these tasks and use them in the current project, it would help a lot.

example:

[tasks.format]
run = 'ruff check . --fix; ruff format .'
alias = 'f'

[tasks.lint]
run = 'ruff check .; ruff check . --diff'
alias = 'l'

[tasks.test]
run = ['pytest -s -x --cov=fast_zero -vv']
alias = 't'

[tasks.build]
run = 'poetry build'
alias = 'b'

[airtonix]

just use an existing skaffolding/generator tool.

[hverlin]

The best thing about mise task runner is that the files are just toml. No need to learn a new syntax. One can use the JSON schema of their editor to get some basic auto-complete

[jdx]

Well, not for file tasks :)

[matleh]

Is there a way to use variables in tasks, like in Makefiles and justfiles (apart from env vars)?

[syhol]

You could use env var likes this:

[env]
compose = "docker compose"

[tasks.start]
run = "$compose up -d"

[tasks.logs]
run = "$compose logs -f"

You should also be able to use tera assignments and variables but for some reason I can't get it to work, I get the following error:

Error loading settings file: TOML parse error at line 3, column 1
  |
3 | {% set compose = "echo" %}
  | ^
invalid key

mise ERROR error parsing config file: ~/Code/sandbox/vars/mise.toml
mise ERROR TOML parse error at line 3, column 1
  |
3 | {% set compose = "echo" %}
  | ^
invalid key

mise ERROR Run with --verbose or MISE_VERBOSE=1 for more information

[matleh]

Yes, using env vars is a possibility but more of a work-around. Would be nice if there were a way to do that without cluttering the env and without the restrictions of env (only strings).

Even if tera vars would work - this would also be restricted to a single run template, AFAIS.

[jdx]

you can't use tera templates just anywhere, it has to be inside strings mise parses as templates

[jdx]

this was easy enough to add though: #3130

[matleh]

Wow - that is great!