I'm glad you're seeing it this way and finding value in it, this was very intentional. I wasn't happy with the status quo with all of the other tools in this space (nix, bazel, buck2, etc) that all force you to adopt everything from day 1. I think of mise as an overlay on existing systems, not a system in itself.

▲

c-hendricks 29 minutes ago | parent [-]

Very quickly mise went from "what's that?" to "I need it everywhere" because of the "overlay on existing systems" approach. It's all over our org at work, and all over the local dev community here. It has also simplified all of our CI and made the random python projects a breeze to run. Great work!

Ironically I pushed for it because it also has tasks that can be written in Bash (we have a mix of Bash scripts and Makefiles for task running across projects while I will die on the hill that shell scripts should be written in a shell script: not Makefile, not a string in a json file, not a string in a yaml file) but we never did get around to that.

▲

jdxcode 23 minutes ago | parent [-]

it was definitely a risky move, env vars are not perfect for this use-case (varargs is awkward) but I'm happy I went with the file tasks setup and the magic comments anyways. It's nice that you're not working in bash-inside-yaml or coming up with a new file type. It is just bash.

	▲	kstrauser 7 minutes ago \| parent [-]
		Agreed, and thank you. Every editor I personally use knows how to edit, highlight, and language server shell scripts. Zero of them, AFAICT, know how to do any of that with a shell script embedded in YAML.