I started writing my tasks in mise (https://mise.jdx.dev/tasks/) instead of just, but I found that others didn’t want to install it. Something about mise being an all-in-one tool—combining asdf/direnv/virtualenv/global npm/task management—made installing it just for the task feature off-putting. At least that's my theory. So, I’m back to using just. I am happy that there isn't a ton of pushback on adding a justfile here and there. Maybe it’s the name—‘just’ feels lightweight and is known to be fast, so people are cool with it.
I'd be surprised if you weren't correct. Perhaps I could improve this a bit with the docs, but ultimately mise is complex and that will put people off no matter how good it is.
I think this is all fine though. I'm hard at work improving mise and will continue to do so for the foreseeable future. If someone is hesitant, I'd rather they wait a year until more kinks have been worked out, docs have been improved, feature gaps are closed, etc. I think this is especially true for tasks which only came out of experimental a few weeks ago.
Or people can just not use it. It's not like this is a business where I make more money when I have more DAU or anything. I just want to build a good tool for building sake after all.
I'm starting to use `mise` for tooling management and task running on greenfield projects, myself. Anything you feel `just` does better with regards to running tasks?
The biggest advantage just has is that it's been around longer, in mise tasks only came out of experimental like a month ago. mise tasks themselves are stable, but there are still experimental things and some portions that need to be used more—like windows. That said, most of the stuff that needs polish are features just doesn't even have.
here's my unashamedly biased thoughts on why I like mise tasks compared to just:
* tool integration - this is the obvious benefit. If you run `mise run test` on CI or wherever it'll setup your toolchains and wire them up automatically
* parallel tasks - I saw this as table-stakes so it's been there since the very beginning
* flags+options - mise tasks are integrated with usage (https://usage.jdx.dev) which provides _very_ comprehensive CLI argument support. We're talking way more than things like flags and default options, as an example, you can even have mise tasks give you custom completion support so you can complete `mise run server --app=<tab><tab>`
* toml syntax - it's more verbose, but I think it's more obvious and easier to learn
* file sources/outputs - I suspect just doesn't want to implement this because it would make it more of a "build tool" and less of a "task runner". I chose to despite having the same position that mise tasks is also not a "build tool". Still, I think even in the world of running tasks you want to only run things if certain files changed often.
* `mise watch` - this is mostly just a simple wrapper around `watchexec -- mise run ...` for now, but it's an area of the codebase I plan to focus on sometime in the next few months. Still, even as a simple wrapper it's a nice convenience.
* "file tasks" - in mise you can define tasks just by being executable and in a directory like "./tasks". This is great for complex scripts since you don't also need to add them to mise.toml.
I have not used just very much, but I did go through the docs and there are a handful of things I like that it definitely does better:
* help customization - it looks like you can split tasks into separate sections which is nice, I don't have that
* invoking multiple recipes - I don't love how this is done in mise with `mise run task1 ::: task2` but I _also_ wanted to make it easy to pass arguments. At least for now, the ":::" won out in the design—but I don't like it. Probably too late to change it anyhow.
* [no-cd] flag - both just and mise run tasks in the directory they're defined, but I prefer how this is overridden in just vs mise.
* expression/substitutions - mise uses tera for templating, which is very flexible, but it requires a bit more verbosity. I like that in just you can just use backticks or reference vars with minimal syntax. Same thing with things like joining paths and coalescing. I have all of this, but the syntax is definitely more verbose in mise. Arguably though, mise's verbosity might be easier to read since it's more obvious what you're saying.
* confirmation - I love that in just you can just add `[confirm]` to get a confirmation dialog for the task. I'm sure we'll get around to this at some point, mise already has confirmation dialogs so it shouldn't be hard to add. The tricky part will be getting it to work right when running a bunch of stuff in parallel.
* task output - I haven't used just that much so I can't actually say that it's "better", but having more control over how tasks are output is definitely a weak part of mise right now and is in need of more functionality like in just how you can add/remove "@" to echo out the command that's running
I want to call out one very silly thing that from reading these github issues sounds crazy. It sounds like both just and taskfile have the same behavior with `.env` files. In just and taskfile, variables defined in .env are ignored if they're already defined. I don't think anyone would want that—nobody has asked for mise to behave that way—and it doesn't appear either tool even allows you to change it!
Hi Jeff, thanks for creating mise! I am gearing up to migrate from asdf, very excited to check it out. Not totally sure we can adopt mise for tasks (we use just) but willing to give it a whirl. Putting run commands into toml sounds like it might be challenging, I wonder if there's syntactic sugar that would help.
most people just put simple tasks into toml (like `npm run test` or something), for anything complex, file tasks are much better: https://mise.jdx.dev/tasks/file-tasks.html
file tasks are basically just a directory of bash (or whatever shebang) scripts, but special comments give them extra functionality like dependencies or defining flags/options.
In the Python ecosystem there has been quite a bit of debate around workflow tools (Hatch, PDM, flit, Poetry etc.) I tried out Poetry starting in probably 2018 or so and eventually realized how much I hated it: it was lagging behind on standards and the install/uninstall process was a moving target. But more than that, it... was an all-in-one tool, with its own definition of "all", almost all of which was irrelevant to me and which I was simply ignoring. I never ended up trying other options because I realized I would still have that same experience - although their various definitions of "all" are not identical.
I very much see the need in the Python ecosystem for a fully integrated user-level tool - something that sets up environments and allows people to use dependencies in their own one-off scripts. Pipx is almost there, if you build some wrappers around it to deal with the fact that it artificially refuses to "install" what it considers "libraries" (i.e. packages that don't define any explicit entry points). But it still is a bit rough around the edges, and more importantly is still based on Pip which has many faults. (I don't blame the design of `venv` for very much if anything, even if it's not quite how I would do things if we could start completely fresh; but it could use some nicer wrappers.)
But for development I've always thought it makes more sense to take a "Unix way" approach. Developers need the user tool for the basic mechanics of setting up packages, and then an actual toolchain built around that, with the chance to select individual tools according to their needs and preferences.
