> A small drawback is that just isn’t readily available on developer’s machines (unlike bash and make)
Looking back, this was usually a substantial stumbling block for adoption of new tooling. Things have changed. All one has to do is look at what JS programmers will go through to scratch build entire toolchains on the back of npm. IMO, the bar has been moved up to allow _some_ installation friction rather than none.
IMO, if the tool is a solid improvement and installation is a one-liner, use it and promote it loudly so it continues to get support.
Historically, I did it the other way around: have some autogenerated shell commands (dev, test, pull...etc) on my local machine that detect which language the project in the current folder is using, and calls commands accordingly.
I did it this way because, in my case, it was challenging to consolidate multiple projects across multiple organizations under a single tool.
Even for projects where Make isn't part of the build pipeline, like Rails or C++, I have a standardized makefile I put in the project root, using includes for "secrets.mk", so I can do things like "make deploy" and it Just Works(tm).
Another neat and simple trick it to have the first target in the Makefile print out a helpful message that tells the reader what the project is and how to use it. One of those things that is useful both when you are working on the project and when you later return to it, years later.
I wish mise has better secrets management or allows for split config e.g. a repo wide config that's to be shared and a personal config that can override whatever's necessary. It's difficult to commit mise.toml because the [env] section almost always contains sensitive variables.
> A small drawback is that just isn’t readily available on developer’s machines (unlike bash and make)
Looking back, this was usually a substantial stumbling block for adoption of new tooling. Things have changed. All one has to do is look at what JS programmers will go through to scratch build entire toolchains on the back of npm. IMO, the bar has been moved up to allow _some_ installation friction rather than none.
IMO, if the tool is a solid improvement and installation is a one-liner, use it and promote it loudly so it continues to get support.
I made a task runner inspired by make's simplicity but purpose-built for running tasks:
Run: Task runner that helps you easily manage and invoke small scripts and wrappers.
https://github.com/TekWizely/run
Do you find yourself using tools like make to manage non-build-related scripts?
Build tools are great, but they are not optimized for general script management.
Run aims to be better at managing small scripts and wrappers, while incorporating a familiar make-like syntax.
Historically, I did it the other way around: have some autogenerated shell commands (dev, test, pull...etc) on my local machine that detect which language the project in the current folder is using, and calls commands accordingly. I did it this way because, in my case, it was challenging to consolidate multiple projects across multiple organizations under a single tool.
It's public, but I realize I haven't pushed my local updates for a while now. https://github.com/Betree/dev-commander
Let me also recommend babashka and it's task runner too!
If my tasks are simple enough, bash or make will do but for serious projects, specially lispy ones, babashka is amazing.
I use the shell script pattern. In bash the case statement at the bottom of your example can be replaced with this though:
I do this with plain ol' makefiles.
Even for projects where Make isn't part of the build pipeline, like Rails or C++, I have a standardized makefile I put in the project root, using includes for "secrets.mk", so I can do things like "make deploy" and it Just Works(tm).
Sometimes the old ways are best!
Another neat and simple trick it to have the first target in the Makefile print out a helpful message that tells the reader what the project is and how to use it. One of those things that is useful both when you are working on the project and when you later return to it, years later.
That's definitely an option, though I prefer to just put a README. No reason you couldn't have the default make target just execute `cat README.md`
I've been using Taskfile. Are just / mise much better?
Taskfile is great but I’ve moved to mise over a year ago and not coming back.
The only think I found Taskfile does better is handling Go’s defer. Misé unfortunately does not have an equivalent.
Mise manages tools, env vars, tasks, bootstrapping , plays well with usage, etc.
People saying "just use makefiles" are missing out.
Not using YAML is huge.
I wish mise has better secrets management or allows for split config e.g. a repo wide config that's to be shared and a personal config that can override whatever's necessary. It's difficult to commit mise.toml because the [env] section almost always contains sensitive variables.
mise looks in a number of places for configuration and recommends using a `mise.local.toml` file for local-only configurations:
https://mise.jdx.dev/configuration.html
the same author has a separate but related project called fnox which focuses on secrets management and integrates with mise:
https://fnox.jdx.dev/
I recommend mise for almost everything.
But we use 1Password for secrets and I have the need to mix and match environment profiles. So I built:
https://github.com/level12/env-config
Are you aware of fnox by the same author?
https://fnox.jdx.dev/
Like someone said, there is fnox by the same author for secrets.
Whatever is truly local (not necessarily secrets ) should go in mise.local.toml and not be version controlled.
You also have MISE_ENV if you want to manage completely different environments.