Your shell env wins. Your CLI args win. Internal `vars:` are defaults, not mandates. A hard fork of go-task where first-in-wins is actually first-in-wins.
brew install clintmod/tap/rite # Homebrew# mise.toml
[tools]
"ubi:clintmod/rite" = "v1.0.3" # mise + ubigo install github.com/clintmod/rite/cmd/rite@latest # from sourceMore options (binary archives, deb/rpm/apk, older-mise fallbacks) on the getting-started page.
go-task's variable model is structurally inverted: task-level vars: override CLI arguments and shell environment, which is the opposite of every Unix convention. The upstream project's planned redesign (go-task/task#2035) preserves the inversion.
rite starts from the opposite premise. The closer a variable is declared to the user, the more authority it has. Your shell environment is law. Internal vars: blocks declare what a value should be if nothing else sets it. Nothing a Ritefile declares internally can override what the user passed on the command line.
See SPEC.md for the full design contract.
A rite is a ritual — a prescribed set of actions performed the same way every time. That's what a task runner is: a script of steps you repeat on every build, every deploy, every release. The word also reads as a near-homophone of right, which fits the project's thesis — variables should behave the way Unix has always done it, i.e. the right way. Short, typable, a nod to task's spiritual ancestor rake, and doesn't collide with anything on PATH.
# Ritefile.yml
version: '3'
vars:
ENV: staging
tasks:
deploy:
vars:
ENV: development # task-scope default
cmds:
- echo "Deploying to ${ENV}"| Invocation | Output | Why |
|---|---|---|
rite deploy | Deploying to staging | Entrypoint vars: wins over task-scope default |
ENV=prod rite deploy | Deploying to prod | Shell env wins over everything |
rite deploy ENV=qa | Deploying to qa | CLI wins over entrypoint and task-scope |
Compare to go-task, where rite deploy ENV=qa would print development because task-scope vars: override CLI args.