Revisit Linux Nerd Fonts installation (standalone, low priority)

[ppat]

Context

.chezmoiscripts/run_after_32_fonts.sh.tmpl is 71 lines that install JetBrainsMono and FiraCode Nerd Fonts on Linux by downloading upstream release archives with curl, unzipping into ~/.local/share/fonts/NerdFonts, and running fc-cache. It carries a hand-pinned NERD_FONTS_VERSION kept current by a # renovate: comment.

It exists because Homebrew font casks only populate the Caskroom and never reach fontconfig on Linux — so the cask approach used on macOS (Brewfile.system.darwin) doesn't work there. That finding is still believed correct and is not what's in question here.

What prompted this

The PoC in #747 replaced this script with two brew-cask: entries under mise's [bootstrap.packages], on the basis that mise is not shelling out to brew --cask — it writes font files directly into $XDG_DATA_HOME/fonts. In a throwaway Ubuntu 24.04 pod that produced 114 .ttf files in ~/.local/share/fonts/ with fontconfig picking them up, and a second run was a no-op.

That work is not being carried forward. PR #748 was closed unmerged, and the repo owner is not convinced the approach is sound enough to adopt on that evidence. This ticket exists so the question isn't silently dropped — not as a commitment to the PoC's design.

No urgency, and no strong value either way. The current script works. The upside is deleting 71 lines of bespoke download/unzip/cache logic plus a hand-pinned version; the downside is depending on a mise mechanism that is weeks old and, in the PoC, needed a conf.d per-OS overlay plus a mise bootstrap packages apply call to work at all.

If picked up

Evaluate fresh rather than resurrecting the PoC's shape:

• Does mise's brew-cask: font path hold up outside a clean pod — on an established machine, across a font version bump, and against fc-cache behaviour with an existing NerdFonts/ directory from the current script?
• What is the minimum machinery? The PoC needed a Linux-only conf.d overlay because [bootstrap.packages] has no per-entry OS filter, and macOS already installs these fonts via Brewfile.system.darwin — so a shared entry would double-install. Is a whole per-OS overlay mechanism worth it for two lines?
• Are there alternatives that don't involve mise at all — e.g. keeping the script but simplifying it, or an apt/distro path.
• Whatever is chosen: preserve the reasoning that Homebrew casks don't reach fontconfig on Linux. If a future reader sees a cask-flavoured approach working and concludes the original investigation was wrong, it wasn't — mise just isn't using brew.

References

• PoC ticket and findings: Phase 1 (PoC): prove three mise mechanisms on a narrow, reversible slice #747 — full findings
• Closed PR containing the implementation and comments: feat(dev-tools): PoC #747 — prove three mise mechanisms on a narrow, reversible slice #748 (conf.d/linux.toml, apply_bootstrap_packages in script_mise.sh, Brewfile.system.linux comment)
• Epic, now closed: Epic: evaluate mise bootstrap as a replacement for Brewfiles and imperative chezmoi script bodies #746

Deliberately not linked as a sub-issue of #746 — this is standalone work, independent of that effort's direction.

[ppat]

Status update — still open, and one correction for whoever picks this up

The epic (#746) is now closed. Its surviving work landed as #753 (#749), #752 (#750) and #755 (#754); the bulk Brewfile migration and the bootstrap-chain phases were rejected, and mise tasks were rejected outright.

This ticket is unaffected and stays open. .chezmoiscripts/run_after_32_fonts.sh.tmpl is untouched on main — 71 lines, still carrying its hand-pinned NERD_FONTS_VERSION under a # renovate: comment.

What the epic's closure changes about the calculus here

The PoC's font approach needed a conf.d per-OS overlay plus a mise bootstrap packages apply call, because [bootstrap.packages] has no per-entry OS filter and macOS already installs these casks via Brewfile.system.darwin. None of that machinery exists on main — with phase 4 rejected, nothing else would use it. So the honest cost of this change is now higher than when the PoC ran: it isn't two declarative lines, it's two lines plus standing up the whole per-OS overlay mechanism for one consumer.

That may still be worth it to delete 71 lines of bespoke curl/unzip/fc-cache and a hand-pinned version. But weigh it as "introduce conf.d + a bootstrap-apply hook to delete a script", not as "swap a script for two config lines."

⚠️ Correction if you do resurrect the conf.d shape from #748

private_dot_config/mise/conf.d/darwin.toml in that closed PR claims overlay precedence is alphabetically first-wins. That is wrong. Measured on mise 2026.8.3 with the values swapped to rule out a value artifact — the winner tracked the filename both times:

files	winner
alpha.toml=0.14.0, zulu.toml=0.15.0	zulu.toml
alpha.toml=0.15.0, zulu.toml=0.14.0	zulu.toml

So it is last-wins, matching the sudoers.d / systemd drop-in convention rather than inverting it. Do not copy that comment forward.

Also undocumented anywhere and more likely to bite: config.toml beats conf.d for the same key — an overlay can add but cannot override a common entry.

And still true from the epic: a wrong-OS overlay is a hard error, not a no-op (mise bootstrap plan --detailed-exitcode returns 1), so any .chezmoiignore gating is load-bearing rather than cosmetic.

The core reasoning in the body above is unchanged: Homebrew casks genuinely do not reach fontconfig on Linux — mise works because it isn't shelling out to brew. Preserve that distinction whatever route is taken.