opencode icon indicating copy to clipboard operation
opencode copied to clipboard

add nix flake and improve nix support for the runtime

Open Alb-O opened this issue 1 month ago • 6 comments

Adds a full Nix flake definition to build the OpenCode binary. Bundle the TUI worker as a separate asset during the Bun build and install it alongside the executable (doesn't affect non-nix builds). Make the runtime prefer the packaged worker for Nix distributions while preserving the existing fallback. The flake's meta description/longDescription may need to be updated.

relates to: #3540 #3739 #462 #1903

Alb-O avatar Nov 04 '25 23:11 Alb-O

I'm in no position to properly review this, but I'd have two suggestions:

  • the version is hardcoded in the flake.nix, maybe it's an idea to builtins.fromJSON the version from a package.json file (e.g. packages/opencode/package.json)?
  • maybe a GitHub Actions workflow so that breakages can be detected early? These tend to eat a few minutes, though.

lrittel avatar Nov 05 '25 00:11 lrittel

thanks for ur feedback @lrittel

I think some people in the discord are also taking looks at it.

rekram1-node avatar Nov 05 '25 02:11 rekram1-node

Currently working on the github workflow to automatically update hashes of build deps in flake.nix. Any preferences around this, i.e. triggers or commits from bot?

Alb-O avatar Nov 05 '25 03:11 Alb-O

prolly the same way we do it for automatic version updates of package.json files? woudl that work

rekram1-node avatar Nov 05 '25 04:11 rekram1-node

Oh boy it was fun trying to get the node modules perfectly reproducible with Bun’s symlink tree, think I found a way though, it builds in github CI and on my local machine now. Next up is support for darwin builds and configuring the workflow automation

Alb-O avatar Nov 05 '25 05:11 Alb-O

amazing thank you @Alb-O

rekram1-node avatar Nov 05 '25 05:11 rekram1-node

Thank you for your work on this! It looks amazing, and I'm really looking forward to it. Resources like this are incredibly helpful as I work on improving the nixpkgs release - something I've been struggling with lately.

delafthi avatar Nov 06 '25 08:11 delafthi

Thank you for the work on this, can't wait to have a proper non-hacked/patched solution for nix!

gabrielrinaldi avatar Nov 07 '25 03:11 gabrielrinaldi

@rekram1-node Ready for reviewing/testing now (especially Mac+Nix users would be good)

nix run github:Alb-O/opencode/nix-support

For specific architectures:

nix run github:Alb-O/opencode/nix-support#packages.aarch64-linux.default nix run github:Alb-O/opencode/nix-support#packages.x86_64-linux.default nix run github:Alb-O/opencode/nix-support#packages.aarch64-darwin.default nix run github:Alb-O/opencode/nix-support#packages.x86_64-darwin.default

Alb-O avatar Nov 07 '25 04:11 Alb-O

@rekram1-node Ready for reviewing/testing now (especially Mac+Nix users would be good)

On aarch64-darwin

 > nix run github:Alb-O/opencode/nix-support
error: hash mismatch in fixed-output derivation '/nix/store/09wqyqc7dvm6s8va3hbwc176py3wrnbi-opencode-node_modules-1.0.39.drv':
         specified: sha256-AwTmHj8CvTBllQUnP4atM58b0bVMjvXi9yRZt1YTVbE=
            got:    sha256-Vu1drIvA5tImD4ajk152AE4HQ6yGE/8SaEgsKwgC4zM=
error: Cannot build '/nix/store/pl7kjk0sb72vq2qhzvwyvxp2fm5w2px6-opencode-1.0.39.drv'.
       Reason: 1 dependency failed.
       Output paths:
         /nix/store/r8sqgkwycljr82kfnpjmqgww9yvpamzl-opencode-1.0.39

It seems something's not right. Running it with

 > nix run github:Alb-O/opencode/nix-support#packages.aarch64-darwin.default
error: hash mismatch in fixed-output derivation '/nix/store/09wqyqc7dvm6s8va3hbwc176py3wrnbi-opencode-node_modules-1.0.39.drv':
         specified: sha256-AwTmHj8CvTBllQUnP4atM58b0bVMjvXi9yRZt1YTVbE=
            got:    sha256-6tHiBvO1ke1m7iEhU2WBqDlxleWdBKtZjhHz/Qh6Fmc=
error: Cannot build '/nix/store/pl7kjk0sb72vq2qhzvwyvxp2fm5w2px6-opencode-1.0.39.drv'.
       Reason: 1 dependency failed.
       Output paths:
         /nix/store/r8sqgkwycljr82kfnpjmqgww9yvpamzl-opencode-1.0.39

yields a different hash.

x86_64-darwin on the other hand worked 🎉

delafthi avatar Nov 07 '25 06:11 delafthi

yields a different hash.

Thank you for testing, these tiny, tiny, differences between the GitHub runner environment and actual user hardware that results in a different hash is driving me a bit mental, but I'll look into it nonetheless. I had it working well on linux x86_64 (exact same hashes between runner and my machine), so maybe an OS/darwin issue? Would be good to know if linux builds are working consistently

Edit: I just realized you meant there was a hash difference between the two different commands which really should give the exact same result. Hm this is a good clue

Alb-O avatar Nov 07 '25 06:11 Alb-O

Ok, may have found the culprit, hopefully this extra optional package pinning solves this. Please test again, same build/run commands as before

Alb-O avatar Nov 07 '25 09:11 Alb-O

Please test again

The situation has reversed: aarch64-darwin now works, but x86_64-darwin fails with a hash mismatch:

> nix run github:Alb-O/opencode/nix-support#packages.x86_64-darwin.default
error: hash mismatch in fixed-output derivation '/nix/store/n8vbgmr3lsn5qixq9gk9y73i673rq3rc-opencode-node_modules-1.0.39.drv':
         specified: sha256-MTZm3ogq4XgsglNzaUCFD3RoHFsjGkaTnyoU4fEn+rI=
            got:    sha256-q1uEMWquAaV1Xd0bzKZKm+S4/uW3xpwadBQU3RPl53U=
error: Cannot build '/nix/store/0yxv492hr4zf4dyjps9m5g5m1wlvngp6-opencode-1.0.39.drv'.
       Reason: 1 dependency failed.
       Output paths:
         /nix/store/231qf56dni35fx7176vd8x5pilc9fpbi-opencode-1.0.39

The x86_64-darwin build produces the same hash on repeated runs, indicating a consistent mismatch.

delafthi avatar Nov 07 '25 15:11 delafthi

aarch64-darwin is failing on the models.dev api.json hash as well:

> nix run github:Alb-O/opencode/nix-support#packages.aarch64-darwin.default
error: hash mismatch in fixed-output derivation '/nix/store/gky155qq5bc9ilwas8r43c5p41gxnhkn-api.json.drv':
         specified: sha256-Q82BpJzo/Gla3M3RHAwhATYV0NxamkdwoVL3iEUbaec=
            got:    sha256-dTUM9lSUErd28jMw/YVWwpD0mZWfTRgzfysfq5KhKjg=

Given that models.dev is external to this repo, I don't think you can have a hard match to api.json that will be sustainable. I think you just have to accept the non-declarativeness of fetching it and taking whatever you're given, maybe with a null fallback, since if you're trying to use opencode in an airgapped environment you probably either know what you're doing or shouldn't be doing it anyway.

ndrwstn avatar Nov 07 '25 16:11 ndrwstn

I encountered this exact issue when I first packaged OpenCode for nixpkgs. The problem stems from fetching from a link which doesn't pin a specific version - whenever api.json gets updated on the server, you'll get a hash mismatch. In other words, the output of that fetchContent isn't consistent.

I solved this by packaging models-dev separately (see the package definition) and then using that as a dependency.

delafthi avatar Nov 07 '25 16:11 delafthi

I don't understand the opencode architecture choice, but it seems like (I just asked an agent; I didn't verify:) opencode will crash on first run if api.json isn't accessible (e.g. offline). As a result, it's included in the build even though it's not really needed (or even desirable, frankly).

I think the right answer is to fix the application to check for connectivity and cleanly error on first-run instead of forcing a download on build, but that's well beyond the scope of making a nix flake. For the moment, since it doesn't matter, you just need to pick a deterministic way of giving opencode something on first-run, whether you refer to nixpkgs models-dev or just pass a null.

ndrwstn avatar Nov 07 '25 19:11 ndrwstn

@ndrwstn the macro is needed so there is a copy of available models when you run opencode

rekram1-node avatar Nov 07 '25 22:11 rekram1-node

Ready to be tested again, models.dev API JSON is now sourced from nixpkgs, and I'm doing extra hash validation on other dependency packages

Same commands as before:

nix run github:Alb-O/opencode/nix-support

For specific architectures:

nix run github:Alb-O/opencode/nix-support#packages.aarch64-linux.default nix run github:Alb-O/opencode/nix-support#packages.x86_64-linux.default nix run github:Alb-O/opencode/nix-support#packages.aarch64-darwin.default nix run github:Alb-O/opencode/nix-support#packages.x86_64-darwin.default

Alb-O avatar Nov 08 '25 06:11 Alb-O

Tested the current version. Success, both x86_64-darwin and aarch64-darwin worked.

delafthi avatar Nov 08 '25 13:11 delafthi

Unfortunately, despite my best efforts, there are STILL sometimes random hash inconsistencies in the node_modules fixed output derivation between the github CI and local builds. The annoying part is it's VERY close to being consistent and matching up exactly with local builds... most of the time. I suspect this slight randomness comes from somewhere in bun's internal build process, and I'm not sure how to solve this. If anyone has ideas, let me know.

Alb-O avatar Nov 11 '25 15:11 Alb-O

This has be working for me on NixOS (apart from the rewrite bugs that I assume are unrelated), has been consistent across multiple builds (I might be getting lucky).

gabrielrinaldi avatar Nov 11 '25 18:11 gabrielrinaldi

This has be working for me on NixOS (apart from the rewrite bugs that I assume are unrelated), has been consistent across multiple builds (I might be getting lucky).

This is probably because I have been manually re-running the CI on my fork immediately after the original run produced a bad linux 86x hash (I'm also using NixOS). Interestingly, if I change the workflow yml around a bit (e.g. removing some jobs/steps) then the linux hash suddenly becomes stable across runs... but the inconsistency problem shifts over to the MacOS hashes instead... 🤪

Alb-O avatar Nov 11 '25 21:11 Alb-O

I just tested nix run github:Alb-O/opencode/nix-support on x86_64 Linux and it worked for me!

patrickjcasey avatar Nov 11 '25 22:11 patrickjcasey

Here's proof of the CI run inconsistencies:

auto-commit on nix-support-dev branch

auto-commit on nix-support branch

The parent commit for both of these are identical (3c160aa), exact same git history up until this point. Yet something is still touching the node_modules result hashes in a non-deterministic way. In this specific case, the linux hashes changed while the mac hashes remained stable...

Alb-O avatar Nov 11 '25 23:11 Alb-O

maybe you can add something to the workflow that saves the node_modules from the store as an artifact so they can be compared locally using something like diffoscope. You can do something like tar.gz up the folder and upload it via actions/upload-artifact with a short expiry window

FWIW this is what i'm getting

error: hash mismatch in fixed-output derivation '/nix/store/ndsb5q1mhcss6x7qwz52jwrpgn0130xx-opencode-node_modules-1.0.58.drv':
           likely URL: (unknown)
            specified: sha256-+dsSECijB/O6dA87Rdm8mcSrPn7FoMaNM4pzgouyFn0=
                  got: sha256-U2bUPxnKrUN6pRIDBIiyrg+CqghaoneSqY4BI5zXs5w=
        expected path: /nix/store/hw9psi0abc8j4pd8n8kl2jbxbph5c5id-opencode-node_modules-1.0.58
             got path: /nix/store/h6p7lqckj4v2d8qhhlima5qkph3wdls4-opencode-node_modules-1.0.58
error: 1 dependencies of derivation '/nix/store/qrlixkk1pg2k9xkjpdsyxk2pn9y153lg-opencode-1.0.58.drv' failed to build
error: 1 dependencies of derivation '/nix/store/nlbh1jymp215cmlrxm1913hwi3wyb1g8-nix-shell-env.drv' failed to build

but the nix-support-dev branch works for me

Ninja3047 avatar Nov 12 '25 05:11 Ninja3047

Hash inconsistency issues seem to be finally resolved, pinpointing the issue to symlinked binaries in node_modules/.bun and .bin, and normalizing these paths during nix builds. Looking nice and stable now 🤞

Alb-O avatar Nov 13 '25 23:11 Alb-O