opencode
opencode copied to clipboard
add nix flake and improve nix support for the runtime
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
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 tobuiltins.fromJSONthe version from apackage.jsonfile (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.
thanks for ur feedback @lrittel
I think some people in the discord are also taking looks at it.
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?
prolly the same way we do it for automatic version updates of package.json files? woudl that work
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
amazing thank you @Alb-O
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.
Thank you for the work on this, can't wait to have a proper non-hacked/patched solution for nix!
@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
@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 🎉
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
Ok, may have found the culprit, hopefully this extra optional package pinning solves this. Please test again, same build/run commands as before
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.
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.
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.
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 the macro is needed so there is a copy of available models when you run opencode
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
Tested the current version. Success, both x86_64-darwin and aarch64-darwin worked.
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.
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 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... 🤪
I just tested nix run github:Alb-O/opencode/nix-support on x86_64 Linux and it worked for me!
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...
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
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 🤞