From feb5883e297764ed6242d68ceb039b6e31a26369 Mon Sep 17 00:00:00 2001 From: Ivan Malison Date: Tue, 10 Feb 2026 20:25:00 -0800 Subject: [PATCH] refactor: split taffybar skill into ecosystem release and NixOS flake chain Separate the taffybar ecosystem release workflow (Hackage publishing, dependency graph, version bounds) from the NixOS flake chain integration (three-layer flake.lock cascade, bottom-up update strategy). Each skill cross-references the other. Co-Authored-By: Claude Opus 4.6 --- .../taffybar-ecosystem-release/SKILL.md | 37 +---------- .../taffybar-nixos-flake-chain/SKILL.md | 61 +++++++++++++++++++ 2 files changed, 63 insertions(+), 35 deletions(-) create mode 100644 dotfiles/agents/skills/taffybar-nixos-flake-chain/SKILL.md diff --git a/dotfiles/agents/skills/taffybar-ecosystem-release/SKILL.md b/dotfiles/agents/skills/taffybar-ecosystem-release/SKILL.md index 796967d5..54236afb 100644 --- a/dotfiles/agents/skills/taffybar-ecosystem-release/SKILL.md +++ b/dotfiles/agents/skills/taffybar-ecosystem-release/SKILL.md @@ -7,6 +7,8 @@ description: Use when releasing, version-bumping, or propagating changes across Release and propagate changes across the taffybar Haskell package ecosystem. +See also: `taffybar-nixos-flake-chain` for how these packages are consumed by the NixOS configuration and what flake.lock updates may be needed after a release. + ## Package Dependency Graph ``` @@ -82,38 +84,3 @@ nix flake update gtk-strut 1. `gtk-strut`, `status-notifier-item`, `dbus-hslogger`, `dbus-menu` (leaves — parallel OK) 2. `gtk-sni-tray` (update bounds for any leaf changes first) 3. `taffybar` (update bounds for all changes) - -## NixOS Configuration Integration - -The personal NixOS config consumes these packages through a chain of flakes. When doing a system rebuild (`just switch` in `~/dotfiles/nixos`), be aware that there are multiple flake.lock files that may need updating depending on what changed. - -``` -nixos/flake.nix (top — `just switch` reads this) -│ ├── taffybar path:.../taffybar/taffybar -│ ├── imalison-taffybar path:../dotfiles/config/taffybar -│ └── gtk-sni-tray, gtk-strut, etc. (GitHub inputs) -│ -dotfiles/config/taffybar/flake.nix (middle — imalison-taffybar) -│ ├── taffybar path:.../taffybar/taffybar -│ └── gtk-sni-tray, gtk-strut, etc. (GitHub inputs) -│ -dotfiles/config/taffybar/taffybar/flake.nix (bottom — taffybar library) -│ └── gtk-sni-tray, gtk-strut, etc. (flake = false GitHub inputs) -``` - -All three flakes declare their own top-level inputs for the ecosystem packages and use `follows` to keep versions consistent. The key thing to understand: `path:` inputs snapshot the target flake **including its flake.lock** at lock time. So if you update only the top-level nixos flake.lock, the middle and bottom layers will still use whatever was previously locked in *their* flake.lock files. - -This means when propagating a change to a system rebuild, you generally need to update flake.lock files **bottom-up** — the bottom layer first so the middle layer picks up fresh locks, then the middle so the top picks up fresh locks: - -```bash -# Bottom (if an ecosystem dep changed): -cd ~/.config/taffybar/taffybar && nix flake update - -# Middle: -cd ~/.config/taffybar && nix flake update taffybar - -# Top: -cd ~/dotfiles/nixos && nix flake update imalison-taffybar taffybar -``` - -Not every change requires touching all three layers. If you only changed taffybar itself, the bottom layer doesn't need updating since it *is* the bottom. If the nixos flake already uses `follows` to override an input from GitHub directly, updating just that top-level input may be sufficient. Think about which flake.lock files actually contain stale references and update those. diff --git a/dotfiles/agents/skills/taffybar-nixos-flake-chain/SKILL.md b/dotfiles/agents/skills/taffybar-nixos-flake-chain/SKILL.md new file mode 100644 index 00000000..6c16dc02 --- /dev/null +++ b/dotfiles/agents/skills/taffybar-nixos-flake-chain/SKILL.md @@ -0,0 +1,61 @@ +--- +name: taffybar-nixos-flake-chain +description: Use when doing NixOS rebuilds involving taffybar, or when flake.lock updates are needed after changing taffybar ecosystem packages. Also use when debugging stale taffybar versions after `just switch`. +--- + +# Taffybar NixOS Flake Chain + +How the taffybar ecosystem packages are consumed by the NixOS configuration through a chain of nested flakes, and what flake.lock updates may be needed when something changes. + +See also: `taffybar-ecosystem-release` for the package dependency graph, release workflow, and Hackage publishing. + +## The Three-Layer Flake Chain + +The NixOS system build pulls in taffybar through three nested flake.nix files: + +``` +nixos/flake.nix (top — `just switch` reads this) +│ ├── taffybar path:.../taffybar/taffybar +│ ├── imalison-taffybar path:../dotfiles/config/taffybar +│ └── gtk-sni-tray, gtk-strut, etc. (GitHub inputs) +│ +dotfiles/config/taffybar/flake.nix (middle — imalison-taffybar config) +│ ├── taffybar path:.../taffybar/taffybar +│ └── gtk-sni-tray, gtk-strut, etc. (GitHub inputs) +│ +dotfiles/config/taffybar/taffybar/flake.nix (bottom — taffybar library) +│ └── gtk-sni-tray, gtk-strut, etc. (flake = false GitHub inputs) +``` + +All three flakes declare their own top-level inputs for the ecosystem packages and use `follows` to keep versions consistent within each layer. + +## Why Bottom-Up Updates Matter + +`path:` inputs snapshot the target flake **including its flake.lock** at lock time. If you only run `nix flake update` at the top (nixos) layer, the middle and bottom layers keep whatever was previously locked in their own flake.lock files. + +So when propagating a change to a system rebuild, you generally need to update flake.lock files from the bottom up — the bottom layer first so the middle layer picks up fresh locks when it re-resolves, then the middle so the top picks up fresh locks. + +```bash +# Bottom (if an ecosystem dep changed): +cd ~/.config/taffybar/taffybar && nix flake update + +# Middle: +cd ~/.config/taffybar && nix flake update taffybar + +# Top: +cd ~/dotfiles/nixos && nix flake update imalison-taffybar taffybar +``` + +Not every change requires touching all three layers. Think about which flake.lock files actually contain stale references: + +- Changed **taffybar itself** — it's the bottom layer, so start at the middle (`nix flake update taffybar`) then the top. +- Changed a **leaf ecosystem package** (e.g. gtk-strut) — start at the bottom since taffybar's flake.lock references it, then cascade up. +- The nixos flake also has **direct GitHub inputs** for ecosystem packages with `follows` overrides. Updating those at the top level may be sufficient if nothing changed in the middle/bottom flake.lock files themselves. + +## Rebuilding + +```bash +cd ~/dotfiles/nixos && just switch +``` + +If taffybar seems stale after a rebuild, check whether the flake.lock at each layer actually points at the expected revision — a missed cascade step is the usual cause.