You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Decision (2026-06-13): not now. npm stays the single distribution channel; npm i -g @sqlanvil/cli. Capturing the analysis so we can revisit deliberately.
Why defer
@sqlanvil/cli is a Node app, so a Homebrew formula doesn't ship a standalone binary — it depends_on "node" and installs the same npm tarball under the hood. It's a wrapper around the npm artifact, not a separate distribution.
Marginal benefit today: cleaner install/upgrade ergonomics (brew manages its own node + isolates under libexec, avoiding npm i -g permission / nvm issues) and a bit of "real tool" signaling. Only helps users who aren't already in the npm ecosystem.
Recurring cost: every release needs a matching formula bump (new url + sha256) or the tap silently lags. Cadence has been fast (1.0.2 → 1.3.0 in ~9 days), so a hand-maintained formula drifts quickly.
The big prize isn't available yet: unqualified brew install sqlanvil requires homebrew-core, which needs notability (stars/usage) we don't have. A personal/org tap only gives brew install sqlanvil/tap/sqlanvil — barely shorter than the npm one-liner, so the tap captures little of the upside.
Revisit when any of these is true
A user actually asks for brew install — real demand signal.
Audience skews Python / data-engineer (common for Supabase) and we hear friction about global npm installs — the one case where the ergonomic win is real.
We automate it — wire a formula bump into a tag-triggered release workflow (the release.yml sketched in SQLAnvil/docs npm_publishing.md §5), so each vX.Y.Z updates the formula's url + sha256 automatically. Maintenance cost → ~0, and a tap becomes essentially free.
Implementation notes (when we do it)
Org tapSQLAnvil/homebrew-tap (new public repo), Formula/sqlanvil.rb. Keep the personal ihistand/homebrew-tap (casks-only: incise) untouched — consistent with the org-tap-for-apps convention.
It's a formula, not a cask (CLI, not a GUI app).
Standard Node-CLI formula shape — fields already known for 1.3.0:
Decision (2026-06-13): not now. npm stays the single distribution channel;
npm i -g @sqlanvil/cli. Capturing the analysis so we can revisit deliberately.Why defer
@sqlanvil/cliis a Node app, so a Homebrew formula doesn't ship a standalone binary — itdepends_on "node"and installs the same npm tarball under the hood. It's a wrapper around the npm artifact, not a separate distribution.libexec, avoidingnpm i -gpermission /nvmissues) and a bit of "real tool" signaling. Only helps users who aren't already in the npm ecosystem.url+sha256) or the tap silently lags. Cadence has been fast (1.0.2 → 1.3.0 in ~9 days), so a hand-maintained formula drifts quickly.brew install sqlanvilrequires homebrew-core, which needs notability (stars/usage) we don't have. A personal/org tap only givesbrew install sqlanvil/tap/sqlanvil— barely shorter than the npm one-liner, so the tap captures little of the upside.Revisit when any of these is true
brew install— real demand signal.release.ymlsketched in SQLAnvil/docsnpm_publishing.md§5), so eachvX.Y.Zupdates the formula'surl+sha256automatically. Maintenance cost → ~0, and a tap becomes essentially free.Implementation notes (when we do it)
SQLAnvil/homebrew-tap(new public repo),Formula/sqlanvil.rb. Keep the personalihistand/homebrew-tap(casks-only: incise) untouched — consistent with the org-tap-for-apps convention.url "https://registry.npmjs.org/@sqlanvil/cli/-/cli-1.3.0.tgz"sha256 "1130001c63fd0d2b9afcfd7803a0f7a59d35cb5971c57483db98cde86f06745f"binentry:sqlanvil→bundle.jsdepends_on "node"; install vianpm install *std_npm_args+ symlink the bin;testassertssqlanvil --versioncontains the version.