8 ms·

Use Task Runners for Common Coding Tasks

77 points by speckx 3mo ago

Onavo 3mo ago
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.
- Volundr 3mo ago
  Are you aware of fnox by the same author? https://fnox.jdx.dev/ https://fnox.jdx.dev/
- coryplastek 3mo ago
  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 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/ https://fnox.jdx.dev/
- LeBit 3mo ago
  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.
- rsyring 3mo ago
  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 https://github.com/level12/env-config
jtwaleson 3mo ago
I've been using Taskfile. Are just / mise much better?
- timw4mail 3mo ago
  Not using YAML is huge.
- LeBit 3mo ago
  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.
  - kstrauser 3mo ago
    I was on the "just use makefiles" boat way too long, except it was Just at the time that was calling for my attention. At first glance, they look similar. Make's already there, so what's the big deal? And then I use Just for a week and become a diehard fan. Yeah, it's similar to make, except optimized for developer ergonomics instead of feature completeness. What if... the tool actually supported and encouraged you instead of making you fight it? Later I came to prefer mise over just. It does more common developer stuff like managing tools and env vars, and I prefer the way it handles embedded scripts. In any case, I vastly prefer either of them to make for the kinds of languages I mostly use. Even if I did prefer make, which one? The GNU make that ships with macOS is ancient, so I'd probably have to install a newer one, and if I'm going to have to install a tool anyone, might as well make the effort to make that tool be mise (or just or just about anything else).
- Arrowmaster 3mo ago
  I have been using just for some projects and really like it. I looked at mise to replace direnv in the few places I use it, but between mise trying to do so many things and the in terminal advertisement for a problematic company I want nothing to do with, I have halted all plans I had for learning more about mise.
stackghost 3mo ago
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!
- adunk 3mo ago
  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.
  - stackghost 3mo ago
    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`
  - evolve-maz 3mo ago
    I use this pattern for my makefiles. First item is for "help", and it dynamically scrapes all the other commands (assuming format <command>: ## <description>). So if I do 'make help' it'll list all the commands in the makefile without much extra work from me. .PHONY: help help: ## Show this help message @grep -E '^[a-zA-Z_-]+:.?## .$$' $(MAKEFILE_LIST) | awk 'BEGIN {FS = ":.*?## "}; {printf "\033[36m%-20s\033[0m %s\n", $$1, $$2}' @echo "" @echo "Examples:" @echo " make deploy" @echo " make deploy-branch BRANCH=feature-x" @echo " make deploy AUTO_START=true" .PHONY: deploy deploy: ## Deploy from current branch (default main) (use AUTO_START=true to restart service after) @$(MAKE) _deploy BRANCH=$(git branch --show-current)
betree 3mo ago
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 https://github.com/Betree/dev-commander
pragma_x 3mo ago
> 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.
danofsteel32 3mo ago
I use the shell script pattern. In bash the case statement at the bottom of your example can be replaced with this though: “${@:-default}” || usage
yolkedgeek 3mo ago
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.
TekWizely 3mo ago
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 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.
aleyan 3mo ago
Also had this issue. I have made a meta-task runner to make discovery and running of already defined make/just/task/npm/etc task targets easier called dela[0]. The ergonomics of running tasks are very similar to the article as you can run a task simply by typing the name of the task in your shell without saying "make" or "npm run" or whatever else that is the actual task runner. The difference is that you just have to install dela without having to change anything in the underlying project repository. Works really well for me! [0] https://github.com/aleyan/dela https://github.com/aleyan/dela
tom_ 3mo ago
I write a Python script for this stuff. argparse with subparsers makes (fairly) light work of creating a command line tool with git-/svn-/etc.-style subcommands, and you get very useful autogenerated --help output. (The fact you have to statically specify your program's command line interface up front is maybe a bit un-pythonic, but it's all the better for it.) Python is always measurably more lines than the Makefile or shell script equivalent, but just think of the effect on your productivity metrics! The standard shutil and subprocess modules are pretty convenient to use as-is. They're a bit syntactically tedious for anything that's a very basic sequence of shell operations, but in exchange you'll never forget to quote the arguments correctly. And I've always found that these processes to tend to grow over time anyway - something that's much easier to handle in Python! There's also far more scope for additional error checking and nicer UX.
BeetleB 3mo ago
just use just! It's really easy to learn - about an afternoon to peruse the docs. And quite capable.
- igor47 3mo ago
  I migrated to mise from just. Mise handles more stuff (tool versions, environment vars) and also has nicer ergonomics for specifying tasks
  - BeetleB 3mo ago
    I'm not going to argue since I haven't used mise, but how beginner friendly is it? The nice thing about "just" is literally the "can learn in an afternoon". When I was in a team of, well, less motivated developers, that mattered. It meant they could modify and maintain the justfile without everything depending on me. Of course, if those aren't dynamics you have to deal with, definitely go with what works. There's also invoke (https://www.pyinvoke.org/ https://www.pyinvoke.org/). I suspect it too is more powerful than just, and I know teams that use them.
    - kstrauser 3mo ago
      One issue with Just is that by default each line in a recipe is executed in a sub shell. Set a variable in line 1 and you can’t use it in line 2. Mise `run` blocks are embedded shell scripts. Alternatively, you can pull those scripts out into individual files so that you can edit them with syntax highlighting etc with any editor that understands shell scripts. Perhaps you can with just now, too, but mise makes it trivially easy. You can get away without a mise.toml at all if you just put your scripts in the right directory.
      - BeetleB 3mo ago
        > One issue with Just is that by default each line in a recipe is executed in a sub shell. Set a variable in line 1 and you can’t use it in line 2. Mise `run` blocks are embedded shell scripts. just supports the same. If you begin a recipe with a shebang (#!/bin/bash), then it dumps the whole recipe to a file and executes it as a shell script. Not limited to bash - you can do the same with Python, etc. As for scripts in their own files vs embedded in a justfile: I've noticed people's opinions vary. Even in my team we'd debate the issue. I prefer them in the justfile so I can read them in one place - as long as it's not huge. Some team members preferred them in their own files.
lubujackson 3mo ago
Oo, I like that header font: https://fonts.google.com/specimen/Germania+One?preview.script=Latn https://fonts.google.com/specimen/Germania+One?preview.scrip...
chickensong 3mo ago
I like to use a handful of stable shell scripts as the entry points, this way you can change the tooling under the hood without having to update related callers. E.g. you can break up with make or mise or whatever, but you don't need to update your CI. Run.sh runs, build.sh builds, etc.
OutOfHere 3mo ago
I like Task: https://taskfile.dev/ https://taskfile.dev/ https://github.com/go-task/task https://github.com/go-task/task

77 points by speckx 3mo ago

Onavo 3mo ago

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.

Volundr 3mo ago
Are you aware of fnox by the same author? https://fnox.jdx.dev/ https://fnox.jdx.dev/
coryplastek 3mo ago
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 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/ https://fnox.jdx.dev/
LeBit 3mo ago
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.
rsyring 3mo ago
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 https://github.com/level12/env-config

jtwaleson 3mo ago

I've been using Taskfile. Are just / mise much better?

timw4mail 3mo ago
Not using YAML is huge.
LeBit 3mo ago
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.
- kstrauser 3mo ago
  I was on the "just use makefiles" boat way too long, except it was Just at the time that was calling for my attention. At first glance, they look similar. Make's already there, so what's the big deal? And then I use Just for a week and become a diehard fan. Yeah, it's similar to make, except optimized for developer ergonomics instead of feature completeness. What if... the tool actually supported and encouraged you instead of making you fight it? Later I came to prefer mise over just. It does more common developer stuff like managing tools and env vars, and I prefer the way it handles embedded scripts. In any case, I vastly prefer either of them to make for the kinds of languages I mostly use. Even if I did prefer make, which one? The GNU make that ships with macOS is ancient, so I'd probably have to install a newer one, and if I'm going to have to install a tool anyone, might as well make the effort to make that tool be mise (or just or just about anything else).
Arrowmaster 3mo ago
I have been using just for some projects and really like it. I looked at mise to replace direnv in the few places I use it, but between mise trying to do so many things and the in terminal advertisement for a problematic company I want nothing to do with, I have halted all plans I had for learning more about mise.

stackghost 3mo ago

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!

adunk 3mo ago
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.
- stackghost 3mo ago
  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`
- evolve-maz 3mo ago
  I use this pattern for my makefiles. First item is for "help", and it dynamically scrapes all the other commands (assuming format <command>: ## <description>). So if I do 'make help' it'll list all the commands in the makefile without much extra work from me. .PHONY: help help: ## Show this help message @grep -E '^[a-zA-Z_-]+:.?## .$$' $(MAKEFILE_LIST) | awk 'BEGIN {FS = ":.*?## "}; {printf "\033[36m%-20s\033[0m %s\n", $$1, $$2}' @echo "" @echo "Examples:" @echo " make deploy" @echo " make deploy-branch BRANCH=feature-x" @echo " make deploy AUTO_START=true" .PHONY: deploy deploy: ## Deploy from current branch (default main) (use AUTO_START=true to restart service after) @$(MAKE) _deploy BRANCH=$(git branch --show-current)

betree 3mo ago

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 https://github.com/Betree/dev-commander

pragma_x 3mo ago

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

danofsteel32 3mo ago

I use the shell script pattern. In bash the case statement at the bottom of your example can be replaced with this though: “${@:-default}” || usage

yolkedgeek 3mo ago

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.

TekWizely 3mo ago

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

aleyan 3mo ago

Also had this issue. I have made a meta-task runner to make discovery and running of already defined make/just/task/npm/etc task targets easier called dela[0]. The ergonomics of running tasks are very similar to the article as you can run a task simply by typing the name of the task in your shell without saying "make" or "npm run" or whatever else that is the actual task runner. The difference is that you just have to install dela without having to change anything in the underlying project repository. Works really well for me! [0] https://github.com/aleyan/dela https://github.com/aleyan/dela

tom_ 3mo ago

I write a Python script for this stuff. argparse with subparsers makes (fairly) light work of creating a command line tool with git-/svn-/etc.-style subcommands, and you get very useful autogenerated --help output. (The fact you have to statically specify your program's command line interface up front is maybe a bit un-pythonic, but it's all the better for it.) Python is always measurably more lines than the Makefile or shell script equivalent, but just think of the effect on your productivity metrics! The standard shutil and subprocess modules are pretty convenient to use as-is. They're a bit syntactically tedious for anything that's a very basic sequence of shell operations, but in exchange you'll never forget to quote the arguments correctly. And I've always found that these processes to tend to grow over time anyway - something that's much easier to handle in Python! There's also far more scope for additional error checking and nicer UX.

BeetleB 3mo ago

just use just! It's really easy to learn - about an afternoon to peruse the docs. And quite capable.

igor47 3mo ago
I migrated to mise from just. Mise handles more stuff (tool versions, environment vars) and also has nicer ergonomics for specifying tasks
- BeetleB 3mo ago
  I'm not going to argue since I haven't used mise, but how beginner friendly is it? The nice thing about "just" is literally the "can learn in an afternoon". When I was in a team of, well, less motivated developers, that mattered. It meant they could modify and maintain the justfile without everything depending on me. Of course, if those aren't dynamics you have to deal with, definitely go with what works. There's also invoke (https://www.pyinvoke.org/ https://www.pyinvoke.org/). I suspect it too is more powerful than just, and I know teams that use them.
  - kstrauser 3mo ago
    One issue with Just is that by default each line in a recipe is executed in a sub shell. Set a variable in line 1 and you can’t use it in line 2. Mise `run` blocks are embedded shell scripts. Alternatively, you can pull those scripts out into individual files so that you can edit them with syntax highlighting etc with any editor that understands shell scripts. Perhaps you can with just now, too, but mise makes it trivially easy. You can get away without a mise.toml at all if you just put your scripts in the right directory.
    - BeetleB 3mo ago
      > One issue with Just is that by default each line in a recipe is executed in a sub shell. Set a variable in line 1 and you can’t use it in line 2. Mise `run` blocks are embedded shell scripts. just supports the same. If you begin a recipe with a shebang (#!/bin/bash), then it dumps the whole recipe to a file and executes it as a shell script. Not limited to bash - you can do the same with Python, etc. As for scripts in their own files vs embedded in a justfile: I've noticed people's opinions vary. Even in my team we'd debate the issue. I prefer them in the justfile so I can read them in one place - as long as it's not huge. Some team members preferred them in their own files.

lubujackson 3mo ago

Oo, I like that header font: https://fonts.google.com/specimen/Germania+One?preview.script=Latn https://fonts.google.com/specimen/Germania+One?preview.scrip...

chickensong 3mo ago

I like to use a handful of stable shell scripts as the entry points, this way you can change the tooling under the hood without having to update related callers. E.g. you can break up with make or mise or whatever, but you don't need to update your CI. Run.sh runs, build.sh builds, etc.

OutOfHere 3mo ago

I like Task: https://taskfile.dev/ https://taskfile.dev/ https://github.com/go-task/task https://github.com/go-task/task