Add a nix flake - #3422
Merged
Merged
Conversation
Recently, my hacked-together env stopped working, probably due to our switching linkers. This pushed me to write a proper Nix packaging for SpacetimeDB, complete with flake and development environment.
Contributor
|
In my machine I get: nix flake check
> Compiling reqwest v0.11.27
> error: could not find native static library `rusty_v8`, perhaps an -L flag is missing?
>
> error: could not compile `v8` (lib) due to 1 previous error
> warning: build failed, waiting for other jobs to finish...
For full logs, run:
nix log /nix/store/nm6mnvx3zsbpc33dfycvilaxbn4rsjvd-spacetimedb-test-1.6.0.drv
error: build of '/nix/store/nm6mnvx3zsbpc33dfycvilaxbn4rsjvd-spacetimedb-test-1.6.0.drv', '/nix/store/zs5myp6ws05nz94cjz1zkb2gzjw5a2s7-spacetimedb-clippy-1.6.0.drv' failed
SpacetimeDB on HEAD (33ff957) via 🐳 orbstack is 📦 v1.6.0 via .NET v8.0.400 via via 🦀 v1.90.0 via ❄️ impure (nix-shell-env) 🥋 wuur phoebe/nix-flake-and-env | ✅ took 33s
❯ |
Contributor
Author
Contributor
Author
|
I've been able to reproduce locally on a MacOS Nix installation, but not by building without Nix on Mac. Doing the thing described above worked fine and didn't reproduce the issue. Given that I'm blocked on this PR, I think I'm going to make the flake error if built on Darwin with a note and move on. |
…pacetimeDB into phoebe/nix-flake-and-env
cloutiertyler
approved these changes
Oct 20, 2025
cloutiertyler
left a comment
Contributor
There was a problem hiding this comment.
Low risk PR, let's get this in to fix issues with building on nix
5 tasks
pull Bot
pushed a commit
to Abaso007/SpacetimeDB
that referenced
this pull request
Jun 29, 2026
Re-enable the Nix flake on aarch64-darwin. PR clockworklabs#3422 added the flake but bailed out on Darwin pending a fix for "could not find native static library `rusty_v8`". With v8 now on 145.0.0 (PR clockworklabs#4073) the build itself works on aarch64-darwin, so this removes the `builtins.abort` guard and fills in the real sha256 for the v145.0.0 rusty_v8 archive on aarch64-darwin. The underlying bug — v8's build.rs writing `librusty_v8.a` outside the locations cargo and crane treat as authoritative — already has a known workaround in PR clockworklabs#3921, but that fix only lives in `.github/workflows/ci.yml` and so does not protect the Nix build. This ports the equivalent guard into the flake as a `preBuild` on `commonArgs`: if the v8 build directory exists but `librusty_v8.a` is missing, clean and rebuild just the v8 crate. With current nixpkgs/crane the file does in fact survive the `buildDepsOnly` → `buildPackage` handoff on aarch64-darwin, so the guard no-ops on the happy path; it is defence-in-depth for the next time crane or nixpkgs shifts. x86_64-darwin and aarch64-linux still use placeholder hashes; users on those platforms will continue to hit the existing fail-then-paste-hash loop documented in `librusty_v8.nix`. # API and ABI breaking changes None. Build-system only, no runtime change. # Expected complexity level and risk 1. # Testing - [x] `nix flake check --no-build` passes on aarch64-darwin. - [x] `nix build .#default` produces working `spacetime`, `spacetimedb-cli`, and `spacetimedb-standalone` binaries; all three report `spacetimedb tool version 2.3.0`. - [x] `nix build .#checks.aarch64-darwin.workspace-fmt` passes. - [x] `nix develop --command rustc --version` succeeds (the command originally reported failing before this change). - [x] Confirmation from a reviewer with x86_64-linux that the change has not regressed the previously working platform. Co-authored-by: Phoebe Goldman <phoebe@clockworklabs.io>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description of Changes
Recently, my hacked-together env stopped working, probably due to our switching linkers. This pushed me to write a proper Nix packaging for SpacetimeDB, complete with flake and development environment.
Some things I haven't been able to figure out (or in some cases, just haven't bothered with):
spacetime --version.API and ABI breaking changes
It's a new thing we have to maintain if we're exposing it to users, but I need to maintain it anyways to be able to develop Spacetime, so...
Expected complexity level and risk
1
Testing
nix flake checklocally.nix buildlocally and then didspacetime start, got an apparently-responsive SpacetimeDB.nix developlocally, thencargo buildandcargo testin the dev shell.