handy: cross-platform frontendDeps FOD + bindgenHook by xilec · Pull Request #1 · philocalyst/nixpkgs

xilec · 2026-04-08T17:36:20Z

Summary

Three commits, rebased on top of your latest handy-cross-platform-deps state:

handy: replace manual bindgen env with rustPlatform.bindgenHook — drops the hand-rolled LIBCLANG_PATH / BINDGEN_EXTRA_CLANG_ARGS block and the llvmPackages input. bindgenHook reads the right libc-cflags from the cc-wrapper automatically, so this is a pure cleanup.
handy: reproducible bun frontendDeps via normalize-install.ts — turns frontendDeps into a per-system fixed-output derivation, calls Handy's new .nix/scripts/normalize-install.ts orchestrator right after bun install --linker=isolated, and stores one hash per hostPlatform.system. Missing systems throw instead of falling back so unsupported builds fail fast with a pointer at the update script.
handy: add passthru.updateScript with custom per-platform refresh — a small update.sh next to package.nix that wraps nix-update and additionally keeps the per-platform frontendDepsHashes table honest on version bumps. Pure bash + sed + awk, self-contained via a nix-shell shebang.

Why

bun install --linker=isolated is not bit-reproducible out of the box, even with a frozen lockfile and a pinned bun version:

Symlink creation order inside .bun/node_modules/ and in each package's private .bin/ is not stable across hosts or filesystems.
Circular peer dependencies (e.g. browserslist ↔ update-browserslist-db, eslint ↔ eslint-utils) hit a timing race in bun's installer: the consumer's wait on the provider is skipped to avoid a deadlock, and whichever side finishes last silently drops one or more .bin/<peer> symlinks. Same bun version + same lockfile + same platform can produce different .bin/ sets between runs. Closest upstream tracker: oven-sh/bun#28147.

Neither of these can be coerced away with install flags. The fix lives in the Handy repo as three small TypeScript passes, orchestrated from a single entry point that this package calls after bun install:

canonicalize-node-modules.ts — rebuilds .bun/node_modules/ symlinks in sorted order, preserving bun's chosen targets.
heal-peer-dep-bins.ts — for every package, reads its peerDependencies, finds each peer's bin field, and adds any missing .bin/<name> entries bun's race dropped. Idempotent: becomes a no-op if bun ever fixes the race upstream.
normalize-bun-binaries.ts — rebuilds every per-package .bin/ in sorted order, preserving bun's targets.

Having the scripts in the Handy source tree (rather than vendored into this package) matches how opencode handles the same class of problem, and means any bun/Handy bump can update the scripts in one place. They live behind cjpais/Handy#1256.

About the single cross-platform hash idea

We originally tried bun install --cpu="*" --os="*" to fetch all platform variants and get one universal hash. It doesn't work: bun's per-package .bin/<tool> entries point at host-matching native binaries (@esbuild/linux-x64 vs @esbuild/darwin-arm64, @rollup/rollup-linux-* vs @rollup/rollup-darwin-*, same for @tailwindcss/oxide-*, @tauri-apps/cli-*, lightningcss-*), so even with every archive downloaded the .bin/ targets still diverge. One hash per system is the only sensible shape.

Note on bun2nix

Still not in nixpkgs (tracked in NixOS#376299). The TODO comment pointing at that issue is preserved.

Test plan

Local NixOS x86_64-linux: nix-build -A handy.passthru.frontendDeps is reproducible and idempotent; nix-build -A handy succeeds end-to-end with full Vulkan GPU acceleration.
GitHub Actions ubuntu-latest (x86_64-linux), ubuntu-24.04-arm (aarch64-linux), macos-latest (aarch64-darwin) — all three produce stable FOD hashes that match the values committed here.
End-to-end build verification on macOS — needs a Mac (philocalyst, when you have a moment).
x86_64-darwin hash — GitHub Actions retired the free macos-13 Intel pool ("macos-13-us-default is not supported"). Filling it in needs either a self-hosted Intel Mac or a paid runner. frontendDepsHashes.x86_64-darwin is deliberately missing from the table so the evaluation throws on that system with a pointer at the update script.

Hashes

system	`frontendDepsHashes` entry
x86_64-linux	`sha256-tJ6LK99dELOiR0BcsTRTt/vLyNamntujLxhBy5Xl/lc=`
aarch64-linux	`sha256-S+dX6ZVgv9dexxIHoa5PxP7e0nxf/d7cKUGty5eEi8A=`
aarch64-darwin	`sha256-DQbogNBQ9izK5GPmoOudqiB2lJvct1vZI2U5lp3WFy8=`
x86_64-darwin	(throws — no free GH Actions runner)

Update flow

passthru.updateScript = ./update.sh; — a custom script in the package directory, not a nix-update-script wrapper. nix-update-script alone cannot keep the per-platform frontendDepsHashes table in sync: it can refresh the entry for the current host, but it does not reset the other platforms' entries, so after a version bump the stale hashes from the previous release silently pass a hash check on any host that just rebuilds without running the update.

The custom script:

nix-update handy bumps version, src.hash, cargoHash.
On a version change, every frontendDepsHashes entry is reset to lib.fakeHash so every unrefreshed host throws loudly instead of silently reusing a stale hash.
handy.passthru.frontendDeps is rebuilt on the current host, the "got:" line is parsed, and the matching entry is written back with the real value.

Running the script again on each target host (or over a remote builder) fills in the rest of the table one entry at a time. Pure bash + sed + awk, wrapped in a nix-shell shebang so maintainers/scripts/update.nix --argstr package handy invokes it as normal — no extra tooling for the maintainer to install.

No in-tree CI workflow needed.

chore(nix): add bun node_modules normalization scripts cjpais/Handy#1256 — the orchestrator scripts this PR calls into. src is temporarily pinned to the HEAD commit of that PR (rev = "681c6a9…", owner = "cjpais"); reverts to tag = "v${finalAttrs.version}" once Add hdevtools NixOS/nixpkgs#1256 merges and a Handy release containing the scripts is cut.
Windows isolated install can re-apply patched dependency per peer variant and fail with EPERM during hardlinking oven-sh/bun#28147 — upstream bun issue for the circular peer-dep race.

philocalyst · 2026-04-08T18:08:40Z

Thanks for this! Unfortunately.. Nixpkgs would not accept the TS, so you'd have to open ANOTHER PR for Handy, and then we could do it exactly like how Opencode does:

      bun install \
        --cpu="*" \
        --frozen-lockfile \
        --filter ./packages/app \
        --filter ./packages/desktop \
        --filter ./packages/opencode \
        --ignore-scripts \
        --no-progress \
        --os="*"

      bun --bun ./nix/scripts/canonicalize-node-modules.ts
      bun --bun ./nix/scripts/normalize-bun-binaries.ts

That would be it, however; I can handle the rest going forward, thanks so much for the effort.

If you want credit, you can update this PR when it merges, otherwise I can just re-implement.

xilec · 2026-04-08T19:02:51Z

Agreed, moved the scripts into the Handy repo: cjpais/Handy#1256

Once it's merged, the nixpkgs package.nix can reference them from src:

bun --bun .nix/scripts/canonicalize-node-modules.ts
bun --bun .nix/scripts/normalize-bun-binaries.ts

xilec · 2026-04-15T13:27:51Z

@philocalyst — big update, rebased cleanly on top of your latest two commits (cctools fix and added structured attrs) and swapped the frontendDeps approach.

TL;DR: bun's isolated install is now bit-reproducible within a platform, and the FOD hash is real. End-to-end nix-build -A handy works on NixOS x86_64, and the helper workflow produced matching CI hashes for both ubuntu-latest and macos-latest.

What changed since the last review

Dropped bun install --cpu="*" --os="*". It can't produce a single cross-platform hash: even with every native variant downloaded, bun's per-package .bin/<tool> symlink still points at the host-matching binary (esbuild, rollup, tauri-cli, oxide, lightningcss, ...). One FOD hash per system is the only thing that holds up.
Added a post-install orchestrator at .nix/scripts/normalize-install.ts in the Handy source tree, called from the buildPhase after bun install. It runs three small passes:
- canonicalize-node-modules.ts — rebuild .bun/node_modules/ symlinks in sorted order.
- heal-peer-dep-bins.ts — add missing .bin/<peer> entries around circular peer dependencies (browserslist ↔ update-browserslist-db, eslint ↔ eslint-utils). This was the non-obvious one: bun's installer races on those pairs and silently drops random .bin/ entries, so the tree wasn't even stable between two runs on the same box. Closest upstream tracker: oven-sh/bun#28147.
- normalize-bun-binaries.ts — rebuild each per-package .bin/ in sorted order.
The healed entries match what bun would have produced without the race, so if bun ever fixes it upstream the pass becomes a no-op and the hash is unchanged.
Filled in real hashes for the two systems we can actually compute:
- x86_64-linux: sha256-tJ6LK99dELOiR0BcsTRTt/vLyNamntujLxhBy5Xl/lc=
- aarch64-darwin: sha256-DQbogNBQ9izK5GPmoOudqiB2lJvct1vZI2U5lp3WFy8=
x86_64-darwin and aarch64-linux are still lib.fakeHash — GH Actions macos-latest is Apple Silicon, and there's no ARM Linux runner available, so I left a TODO explaining what's needed.
Helper workflow handy-frontend-hashes.yml is the same shape as before: rewrites the hashes to lib.fakeHash, builds on ubuntu-latest + macos-latest, captures hashes into the job summary, and rebuilds for a sanity check. Triggered by push to the branch or workflow_dispatch. For future Handy bumps, one push is enough to get fresh hashes for both platforms.

Temporary `src` override

src currently points at xilec/Handy at commit 681c6a9 (the head of cjpais/Handy#1256) so the orchestrator scripts are actually present in the source tree. Once NixOS#1256 lands and a Handy release containing the scripts is cut (0.8.3 or whatever comes next), this reverts to owner = "cjpais"; tag = "v${finalAttrs.version}" and the comment goes away. Flagged inline with a clear # TEMPORARY: block so it won't be forgotten.

What I'd appreciate from you

A look at the overall shape — particularly the buildPhase invoking bun --bun "$PWD/.nix/scripts/normalize-install.ts" after the usual bun install.
When you have a moment on a Mac, the full end-to-end build (nix-build -A handy). I was only able to verify the hash side on CI and ran the full build locally on Linux; the Handy.app wrapping on darwin is your territory.
If there's a reason to prefer a different strategy for the missing x86_64-darwin / aarch64-linux hashes (throwing vs lib.fakeHash vs something else), I'm happy to adjust.

Thanks for the patience on this one — took a while to figure out the race was real and not something I was causing with my own scripts.

philocalyst · 2026-04-15T13:42:43Z

If possible CI runners for all platforms would be the preference, throwing fakeHash would be the right option until then, however. If the runners are meant to be for when Handy updates, the most idiomatic thing to do would be add a custom update script, which nixpkgs would accept and then we don't need to maintain any infrastructure ourselves. There's plenty of examples in nixpkgs of this ! CI would be good for testing up until merge though.. ▰▰▰▰▰ Miles Wirth 🙃

…

From: Evgeny Khudoba ***@***.***> Sent: 15 April 2026 06:28 To: philocalyst/nixpkgs ***@***.***> Cc: Miles Wirht ***@***.***>, Mention ***@***.***> Subject: Re: [philocalyst/nixpkgs] handy: cross-platform frontendDeps FOD + bindgenHook (PR #1) xilec left a comment (philocalyst/nixpkgs#1) @philocalyst — big update, rebased cleanly on top of your latest two commits (`cctools fix` and `added structured attrs`) and swapped the frontendDeps approach. **TL;DR:** bun's isolated install is now bit-reproducible within a platform, and the FOD hash is real. End-to-end `nix-build -A handy` works on NixOS x86_64, and the helper workflow produced matching CI hashes for both `ubuntu-latest` and `macos-latest`. ### What changed since the last review 1. **Dropped `bun install --cpu="*" --os="*"`.** It can't produce a single cross-platform hash: even with every native variant downloaded, bun's per-package `.bin/<tool>` symlink still points at the host-matching binary (esbuild, rollup, tauri-cli, oxide, lightningcss, ...). One FOD hash per system is the only thing that holds up. 2. **Added a post-install orchestrator** at `.nix/scripts/normalize-install.ts` in the Handy source tree, called from the buildPhase after `bun install`. It runs three small passes: - `canonicalize-node-modules.ts` — rebuild `.bun/node_modules/` symlinks in sorted order. - `heal-peer-dep-bins.ts` — add missing `.bin/<peer>` entries around circular peer dependencies (`browserslist ↔ update-browserslist-db`, `eslint ↔ eslint-utils`). This was the non-obvious one: bun's installer races on those pairs and silently drops random `.bin/` entries, so the tree wasn't even stable between two runs on the same box. Closest upstream tracker: [oven-sh/bun#28147](oven-sh/bun#28147). - `normalize-bun-binaries.ts` — rebuild each per-package `.bin/` in sorted order. The healed entries match what bun would have produced without the race, so if bun ever fixes it upstream the pass becomes a no-op and the hash is unchanged. 3. **Filled in real hashes** for the two systems we can actually compute: - `x86_64-linux`: `sha256-tJ6LK99dELOiR0BcsTRTt/vLyNamntujLxhBy5Xl/lc=` - `aarch64-darwin`: `sha256-DQbogNBQ9izK5GPmoOudqiB2lJvct1vZI2U5lp3WFy8=` `x86_64-darwin` and `aarch64-linux` are still `lib.fakeHash` — GH Actions `macos-latest` is Apple Silicon, and there's no ARM Linux runner available, so I left a TODO explaining what's needed. 4. **Helper workflow** `handy-frontend-hashes.yml` is the same shape as before: rewrites the hashes to `lib.fakeHash`, builds on ubuntu-latest + macos-latest, captures hashes into the job summary, and rebuilds for a sanity check. Triggered by push to the branch or `workflow_dispatch`. For future Handy bumps, one push is enough to get fresh hashes for both platforms. ### Temporary `src` override `src` currently points at `xilec/Handy` at commit `681c6a9` (the head of cjpais/Handy#1256) so the orchestrator scripts are actually present in the source tree. Once #1256 lands and a Handy release containing the scripts is cut (0.8.3 or whatever comes next), this reverts to `owner = "cjpais"; tag = "v${finalAttrs.version}"` and the comment goes away. Flagged inline with a clear `# TEMPORARY:` block so it won't be forgotten. ### What I'd appreciate from you - A look at the overall shape — particularly the buildPhase invoking `bun --bun "$PWD/.nix/scripts/normalize-install.ts"` after the usual bun install. - When you have a moment on a Mac, the full end-to-end build (`nix-build -A handy`). I was only able to verify the hash side on CI and ran the full build locally on Linux; the `Handy.app` wrapping on darwin is your territory. - If there's a reason to prefer a different strategy for the missing `x86_64-darwin` / `aarch64-linux` hashes (throwing vs `lib.fakeHash` vs something else), I'm happy to adjust. Thanks for the patience on this one — took a while to figure out the race was real and not something I was causing with my own scripts. -- Reply to this email directly or view it on GitHub: #1 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

xilec · 2026-04-15T13:47:53Z

Follow-up update, three small changes on top:

Extended the helper workflow matrix from 2 runners to 4 (ubuntu-latest, ubuntu-24.04-arm, macos-13, macos-latest) so it covers every system handy supports.

Real hashes for three of four systems:

system	`frontendDepsHashes` entry
x86_64-linux	`sha256-tJ6LK99dELOiR0BcsTRTt/vLyNamntujLxhBy5Xl/lc=`
aarch64-linux	`sha256-S+dX6ZVgv9dexxIHoa5PxP7e0nxf/d7cKUGty5eEi8A=`
aarch64-darwin	`sha256-DQbogNBQ9izK5GPmoOudqiB2lJvct1vZI2U5lp3WFy8=`
x86_64-darwin	`lib.fakeHash` (blocked on runner availability)

x86_64-darwin is the one outlier — GitHub Actions no longer has a free macos-13 Intel image in the hosted pool, and the job fails immediately with "macos-13-us-default is not supported". Filling it in needs a self-hosted Intel Mac or a paid runner. The workflow keeps macos-13 in the matrix so a future workflow_dispatch on such a runner produces the value without any code change.

Switched the temporary src to fetch via owner = "cjpais" instead of the fork. The commit is the same 681c6a9… (HEAD of chore(nix): add bun node_modules normalization scripts cjpais/Handy#1256); GitHub serves PR commits from the base repository, so fetchFromGitHub { owner = "cjpais"; rev = "681c6a9…"; } works directly and is less confusing to read than indirecting through xilec/Handy. The tarball is byte-identical either way.

About the failing `Build / darwin: shell` PR check

FYI — just looked at it, and it's a pre-existing nixpkgs CI infrastructure flake, unrelated to anything in this PR. The step that fails is

nix-env --install -f nixpkgs/trusted-pinned -A nix-build-uncached

and the error is a syntax error parsing an empty trusted-pinned/pkgs/top-level/impure.nix on the darwin runner. That file is not touched by this PR, and the other three platforms (x86_64-linux, aarch64-linux, and the eval jobs) pass. Looks like a checkout race on macOS that happens outside our changes.

`bindgenHook` reads `libc-cflags` directly from the cc-wrapper, which already contains the correct `.dev` include paths, so we can drop both the manual `LIBCLANG_PATH` / `BINDGEN_EXTRA_CLANG_ARGS` block and the `llvmPackages` input. Less surface area and less chance of the libc-vs-libc.dev mixup that usually lurks behind hand-rolled bindgen env on NixOS.

`bun install --linker=isolated` is not bit-reproducible on its own: symlink creation order in `.bun/node_modules/` and in each package's `.bin/` directory is not stable, and a timing race in bun's installer silently drops some `.bin/<peer>` entries around circular peer dependencies (e.g. `browserslist ↔ update-browserslist-db`, `eslint ↔ eslint-utils`). See `oven-sh/bun#28147` for the closest upstream tracker. Handy ships a tiny post-install orchestrator at `.nix/scripts/normalize-install.ts` (added in cjpais/Handy#1256) that runs three passes — canonicalize, heal, normalize — producing a stable, idempotent `node_modules/` tree. The buildPhase invokes that single entry point right after `bun install`. Within a platform the tree is now deterministic, but bun still only downloads the host-matching native binaries (esbuild, rollup, tauri-cli, lightningcss, tailwindcss-oxide, ...), so the hash differs between systems. Store one hash per `hostPlatform.system`; missing platforms `throw` rather than fall back to a placeholder. Currently populated: x86_64-linux sha256-tJ6LK99dELOiR0BcsTRTt/vLyNamntujLxhBy5Xl/lc= aarch64-linux sha256-S+dX6ZVgv9dexxIHoa5PxP7e0nxf/d7cKUGty5eEi8A= aarch64-darwin sha256-DQbogNBQ9izK5GPmoOudqiB2lJvct1vZI2U5lp3WFy8= `x86_64-darwin` is the only hole: GitHub Actions no longer hosts a free `macos-13` Intel image, so we cannot compute it without a self-hosted or paid runner. The throw-on-missing surfaces that fact immediately when the build is requested there. Also expose `frontendDeps` via `passthru` so the update script and other tooling can build it directly without dragging in the full handy compile. `src` is temporarily pinned to the HEAD commit of cjpais/Handy#1256 so the orchestrator scripts are actually present in the source tree; reverts to `tag = "v${finalAttrs.version}"` once that PR merges and a Handy release containing the scripts is cut.

xilec · 2026-04-15T15:40:02Z

@philocalyst — applied your feedback, thanks.

Rewrote the branch as three clean commits on top of your latest (handy: added structured attrs):

handy: replace manual bindgen env with rustPlatform.bindgenHook — isolated cleanup, independent of the FOD work.
handy: reproducible bun frontendDeps via normalize-install.ts — per-platform frontendDepsHashes + orchestrator wiring + throw on missing platforms. No ad-hoc CI workflow committed in the tree.
handy: add passthru.updateScript with custom per-platform refresh — a small ./update.sh next to package.nix. nix-update-script alone cannot keep frontendDepsHashes honest across a version bump: it can refresh the entry for the current host, but leaves the other platforms' old values in place, so a stale hash from the previous release quietly passes a hash check on any host that rebuilds without running the update. The script wraps nix-update (for version + src + cargo) and then, only when the version actually changed, resets every frontendDepsHashes entry to lib.fakeHash before rebuilding the current host's entry. Each target host still needs a separate run (or a remote builder), but every unrefreshed host fails loud instead of silently using stale data. Pure bash + sed + awk, wrapped in a nix-shell shebang so maintainers/scripts/update.nix --argstr package handy invokes it without any extra local setup.

Three of four systems have real hashes:

system	hash
x86_64-linux	`sha256-tJ6LK99dELOiR0BcsTRTt/vLyNamntujLxhBy5Xl/lc=`
aarch64-linux	`sha256-S+dX6ZVgv9dexxIHoa5PxP7e0nxf/d7cKUGty5eEi8A=`
aarch64-darwin	`sha256-DQbogNBQ9izK5GPmoOudqiB2lJvct1vZI2U5lp3WFy8=`

x86_64-darwin throws instead of lib.fakeHash. GitHub Actions retired the free Intel macOS pool (macos-13-us-default is not supported on dispatch), so there is no way to populate that one entry with the hosted-runners-only setup we have today. The throw includes a one-liner pointer at the update script so a drive-by build on that system fails fast and useful.

Once a self-hosted or paid Intel Mac is available, a single nix-update handy run there will fill it in without any further code change.

On the helper CI workflow

Kept it out of the upstream PR per your preference. The computation was useful for proving reproducibility during development, but it lives on a separate handy-cross-platform-deps-dev branch in my fork now — not in anything you'd merge. Happy to share the yaml if you ever want to run the same matrix against a version bump before it lands.

About the failing `Build / darwin: shell` check

Just looked at it — pre-existing nixpkgs CI infrastructure flake, not touched by this PR. The step that fails is nix-env --install -f nixpkgs/trusted-pinned -A nix-build-uncached, and the error is a syntax error parsing an empty trusted-pinned/pkgs/top-level/impure.nix on the darwin runner. That file is not touched by this PR, the other platforms pass, and this is presumably a checkout race that's been seen on darwin runners before. Should be safe to ignore for the purposes of this review.

Temporary `src` override

Still pinned to the HEAD commit of cjpais/Handy#1256 (rev = "681c6a991b7e55bd04ef9963aeb45767ebacba2e"), but now via owner = "cjpais" rather than indirecting through xilec/Handy — GitHub serves PR commits from the base repository, so the tarball is byte-identical and the # TEMPORARY: block only references cjpais/Handy. Reverts to tag = "v${finalAttrs.version}" the moment NixOS#1256 merges and a Handy release is cut.

`nix-update-script` alone cannot keep the per-platform `frontendDepsHashes` table in sync: it can refresh the entry for the current host via `--subpackage frontendDeps`, but it does not reset the other platforms' entries, so after a version bump the stale hashes from the previous release stay in place and eventually pass a hash check on any host that just rebuilds without running the script. The custom update script at `pkgs/by-name/ha/handy/update.sh` plugs that gap: 1. `nix-update handy` bumps `version`, `src.hash`, `cargoHash`. 2. On a version change, every `frontendDepsHashes` entry is reset to `lib.fakeHash` so the package throws on any host until a fresh hash is computed there. 3. `handy.passthru.frontendDeps` is rebuilt on the current host, the "got:" line is parsed, and the matching entry is written back with the real value. Running the script on each target host (or via remote builders) refreshes the table one entry at a time, without silently reusing stale data from the previous release. The update flow is pure shell + `sed` + `awk`, wrapped in a `nix-shell` shebang so the required tooling (`nix-update`, `nix`, ...) is fetched automatically when `maintainers/scripts/update.nix --argstr package handy` is invoked.

xilec · 2026-04-15T16:15:49Z

@philocalyst — quick note on the failing Build / darwin: shell check — it's a stable nixpkgs-side infrastructure flake, not introduced by this PR. Retried the run; same outcome. The darwin runner's actions/checkout step truncates a bunch of files it "successfully" writes, and one of the truncated files (trusted-pinned/pkgs/top-level/impure.nix) is what the next step tries to parse. None of the affected files are touched by this PR.

From my side I think this is ready to merge. All four Eval/* jobs (including darwin), both linux build matrices, and every lint/check are green.

philocalyst · 2026-04-16T18:35:01Z

Needs an update as your PR was merged. I would also check if it's possible to use the default update hook with some custom params. The code I would say is over-commented which is a no-go.. too

xilec · 2026-04-16T19:42:22Z

Trimmed comments in package.nix and update.sh (9935d04).

Checked nix-update-script — it can't manage per-platform frontendDepsHashes, so the custom update.sh stays (added a one-liner explaining why).

Ok. Waiting on cjpais/Handy#1256 merge.

xilec · 2026-04-19T14:08:43Z

cjpais/Handy#1256 is merged.

Once cjpais cuts a Handy v0.8.3 release, I'll flip src from the pinned rev back to tag = "v${finalAttrs.version}".

philocalyst · 2026-04-19T15:03:26Z

Sweet! BTW the Darwin build is still stubbed... Asked around at Handy discord and they had no advice :( ▰▰▰▰▰ Miles Wirth 🙃

…

From: Evgeny Khudoba ***@***.***> Sent: 19 April 2026 07:09 To: philocalyst/nixpkgs ***@***.***> Cc: Miles Wirht ***@***.***>, Mention ***@***.***> Subject: Re: [philocalyst/nixpkgs] handy: cross-platform frontendDeps FOD + bindgenHook (PR #1) xilec left a comment (philocalyst/nixpkgs#1) cjpais/Handy#1256 is merged. Once cjpais cuts a Handy v0.8.3 release, I'll flip `src` from the pinned `rev` back to `tag = "v${finalAttrs.version}"`. -- Reply to this email directly or view it on GitHub: #1?email_source=notifications&email_token=A3MQBNBAUIAQ2VO2VPDA2AD4WTMYDA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMRXGYYDONBZHAYKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJNLQOJPWG33NNVSW45C7N5YGK3S7MNWGSY3L#issuecomment-4276074980 You are receiving this because you were mentioned. Message ID: ***@***.***>

Backports Darwin-specific build logic from philocalyst/nixpkgs#1's package.nix into flake.nix (conditional on isDarwin: swift, cctools, cargo-tauri.hook, .app bundling, FOD frontendDeps, rpath patch) and adds a macos-latest CI workflow that runs `nix build .#handy` and diagnoses the resulting binary (file/otool/nm/size + try-run) to reproduce the cargo-tauri stub-binary issue from NixOS/nixpkgs#507754. Debug branch only — not intended for upstream.

apple-sdk_26's setup hook exposes FoundationModels.framework via SDKROOT, so build.rs compiles the real apple_intelligence.swift instead of the fallback stub — enabling Apple Intelligence at runtime on macOS 26+.

philocalyst · 2026-04-21T03:02:30Z

So you're really going for it! This is getting impressive, actually, wow.

So, still no. But my guess is you can push the binary size past 3.7mb (maybe 10mb for safety) that would be the signal to look for. So you could add that check in CI, you could get a good feedback loop going.

If you manage to get it up, I'll do everything in my power to get it merged quickly, this is very very cool of you.

Without this swiftc flag the app exits with 0 immediately on nixpkgs Darwin stdenv, because the open-source ld64 picks Swift's synthetic `_main` over Rust's. The fix is one line in src-tauri/build.rs. Cargo.lock, package.json and bun.lock are unchanged between the old and new src rev, so cargoHash and frontendDepsHashes remain valid.

xilec · 2026-04-21T03:37:52Z

@philocalyst Quick clarification — I think two different "stubs" are getting conflated here:

Swift _main stub — the actual startup bug. Fixed in fix(nix): Fix for macOS build for nixpkgs cjpais/Handy#1316.
apple-sdk — needed to enable AI post-processing on Mac via the built-in Apple Intelligence framework.

I just pushed d4eecf0c6 that pins src to the HEAD of NixOS#1316 so you can nix-build and verify directly. Could you give it another try on your Mac?

philocalyst · 2026-04-21T03:48:11Z

I got: structuredAttrs is enabled Running phase: unpackPhase unpacking source archive /nix/store/mhwji9pjvbdnd0jviwiy13sp0k8fpmx7-source source root is source Executing cargoSetupPostUnpackHook Finished cargoSetupPostUnpackHook Running phase: patchPhase patching file src-tauri/build.rs Hunk #3 FAILED at 171. 1 out of 3 hunks FAILED -- saving rejects to file src-tauri/build.rs.rej For full logs, run: nix log /nix/store/ii3ac1dnwy2ynlkysnx2f789pz0ymadq-handy-0.8.2.drv Last time you asked I ran the binary and it did nothing, so that's what I'm referring to. ▰▰▰▰▰ Miles Wirth 🙃

…

From: Evgeny Khudoba ***@***.***> Sent: 20 April 2026 20:38 To: philocalyst/nixpkgs ***@***.***> Cc: Miles Wirht ***@***.***>, Mention ***@***.***> Subject: Re: [philocalyst/nixpkgs] handy: cross-platform frontendDeps FOD + bindgenHook (PR #1) xilec left a comment (philocalyst/nixpkgs#1) Quick clarification — I think two different "stubs" are getting conflated here: 1. **Swift `_main` stub** — the actual startup bug. Fixed in cjpais/Handy#1316. 2. **apple-sdk** — needed to enable AI post-processing on Mac via the built-in Apple Intelligence framework. I just pushed `d4eecf0c6` that pins `src` to the HEAD of #1316 so you can `nix-build` and verify directly. Could you give it another try on your Mac? -- Reply to this email directly or view it on GitHub: #1?email_source=notifications&email_token=A3MQBNACMUZOBXLLSXGYTMT4W3UKNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMRYGU3TMNBXGEZ2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJNLQOJPWG33NNVSW45C7N5YGK3S7MNWGSY3L#issuecomment-4285764713 You are receiving this because you were mentioned. Message ID: ***@***.***>

Hunk 3 of the patch failed to apply because cjpais/Handy#1316 added `-parse-as-library` (with explanatory comment) right where the patch expected `-target` to follow `"swiftc"`. Regenerated against current src; the substantive change (drop xcrun wrapper, call swiftc directly) is unchanged.

xilec · 2026-04-21T03:59:46Z

@philocalyst Patch was the issue, not the source — Hunk 3 of use-nix-swift.patch expected -target immediately after "swiftc", but NixOS#1316 added -parse-as-library between them. Just pushed 7da3037ec with the patch regenerated against NixOS#1316's build.rs. Want to give it another try?

If it works for you this time, would you mind dropping a quick note on cjpais/Handy#1316 confirming the fix? An independent macOS verification would help cjpais review and merge it faster.

philocalyst · 2026-04-21T15:36:51Z

WOW!!! Yes!!! It works :)

Overjoyed.

vulkan-loader and onnxruntime are already in the wrapped binary's RPATH via auto-rpath from buildInputs (DT_NEEDED → stdenv ld wrapper). The explicit --prefix LD_LIBRARY_PATH was a no-op. Verified with patchelf --print-rpath after nix-build: both ${onnxruntime}/lib and ${vulkan-loader}/lib remain in RPATH.

The SDKROOT/SWIFTC env-var fallbacks in build.rs are now part of cjpais/Handy#1316 alongside -parse-as-library, so the local patch is no longer needed. Bump src.rev to the new HEAD of NixOS#1316.

cjpais/Handy#1316 (-parse-as-library swiftc fix + SDKROOT/SWIFTC env-var fallbacks) shipped in v0.8.3, so revert `src` from the in-flight rev pin back to `tag = "v${finalAttrs.version}"`. bun.lock unchanged between v0.8.2 and v0.8.3, so frontendDepsHashes remain valid; cargoHash bumped due to the version field in src-tauri/Cargo.toml.

xilec · 2026-04-28T01:10:36Z

@philocalyst v0.8.3 just shipped, so I've reverted src from the rev pin back to tag = "v${finalAttrs.version}". frontendDepsHashes unchanged on all three supported systems (verified via CI — bun.lock didn't move); cargoHash and src.hash bumped. Linux build green locally.

xilec · 2026-04-28T01:27:50Z

@philocalyst the failing Bot / run check is unrelated to this PR — it's calling GET /api.github.com/orgs/philocalyst, which 404s because philocalyst is a user, not an organization. It will work normally once this lands on NixOS/nixpkgs (org-owned). All other checks are green.

From my side this PR looks ready to merge.

philocalyst · 2026-04-28T01:37:31Z

All good! Now onto merging into nixpkgs! THANK YOU for you effort.

xilec mentioned this pull request Apr 8, 2026

handy: init at 0.8.3 NixOS/nixpkgs#507754

Open

13 tasks

xilec mentioned this pull request Apr 11, 2026

chore(nix): add bun node_modules normalization scripts cjpais/Handy#1256

Merged

7 tasks

github-actions Bot requested a review from philocalyst April 14, 2026 23:33

github-actions Bot added 12.first-time contribution 10.rebuild-darwin: 1 10.rebuild-darwin: 1-10 10.rebuild-linux: 1 10.rebuild-linux: 1-10 6.topic: continuous integration 6.topic: policy discussion labels Apr 14, 2026

xilec force-pushed the handy-cross-platform-deps branch from 3548978 to 1988b96 Compare April 15, 2026 13:20

xilec added 2 commits April 15, 2026 21:08

xilec force-pushed the handy-cross-platform-deps branch from 2865096 to 852007e Compare April 15, 2026 14:19

github-actions Bot removed the 6.topic: continuous integration label Apr 15, 2026

xilec force-pushed the handy-cross-platform-deps branch from 852007e to 5ed3837 Compare April 15, 2026 15:37

xilec force-pushed the handy-cross-platform-deps branch from 5ed3837 to 26b6ef9 Compare April 15, 2026 16:00

handy: reduce comment verbosity

9b621cf

xilec force-pushed the handy-cross-platform-deps branch from 9935d04 to 9b621cf Compare April 16, 2026 20:14

handy: enable Apple Intelligence on Darwin via apple-sdk_26

f60abb3

apple-sdk_26's setup hook exposes FoundationModels.framework via SDKROOT, so build.rs compiles the real apple_intelligence.swift instead of the fallback stub — enabling Apple Intelligence at runtime on macOS 26+.

xilec mentioned this pull request Apr 25, 2026

fix(nix): Fix for macOS build for nixpkgs cjpais/Handy#1316

Merged

4 tasks

xilec added 2 commits April 26, 2026 03:35

handy: drop use-nix-swift.patch (now upstream in cjpais/Handy#1316)

e2b5cd3

The SDKROOT/SWIFTC env-var fallbacks in build.rs are now part of cjpais/Handy#1316 alongside -parse-as-library, so the local patch is no longer needed. Bump src.rev to the new HEAD of NixOS#1316.

xilec force-pushed the handy-cross-platform-deps branch from d5b276d to e2b5cd3 Compare April 25, 2026 21:28

philocalyst merged commit 1cdb58c into philocalyst:handy Apr 28, 2026
22 of 23 checks passed

Conversation

xilec commented Apr 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Why

About the single cross-platform hash idea

Note on bun2nix

Test plan

Hashes

Update flow

Related

Uh oh!

philocalyst commented Apr 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xilec commented Apr 8, 2026

Uh oh!

xilec commented Apr 15, 2026

What changed since the last review

Temporary src override

What I'd appreciate from you

Uh oh!

philocalyst commented Apr 15, 2026 via email

Uh oh!

xilec commented Apr 15, 2026

About the failing Build / darwin: shell PR check

Uh oh!

xilec commented Apr 15, 2026

On the helper CI workflow

About the failing Build / darwin: shell check

Temporary src override

Uh oh!

xilec commented Apr 15, 2026

Uh oh!

philocalyst commented Apr 16, 2026

Uh oh!

xilec commented Apr 16, 2026

Uh oh!

xilec commented Apr 19, 2026

Uh oh!

philocalyst commented Apr 19, 2026 via email

Uh oh!

philocalyst commented Apr 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xilec commented Apr 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

philocalyst commented Apr 21, 2026 via email

Uh oh!

xilec commented Apr 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

philocalyst commented Apr 21, 2026

Uh oh!

xilec commented Apr 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xilec commented Apr 28, 2026

Uh oh!

Uh oh!

philocalyst commented Apr 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

xilec commented Apr 8, 2026 •

edited

Loading

philocalyst commented Apr 8, 2026 •

edited

Loading

Temporary `src` override

About the failing `Build / darwin: shell` PR check

About the failing `Build / darwin: shell` check

Temporary `src` override

philocalyst commented Apr 21, 2026 •

edited

Loading

xilec commented Apr 21, 2026 •

edited

Loading

xilec commented Apr 21, 2026 •

edited

Loading

xilec commented Apr 28, 2026 •

edited

Loading