Repository navigation
build: evaluate Nix to improve dx and builds #1362
Description
Activity
- added a parent issue
on May 13, 2026 Nix evaluation — proposed adoption plan
After evaluating a local Nix devshell on a branch, the proposal is to adopt Nix incrementally over five PRs. Each PR has a single visible exit criterion and leaves the existing mise-based workflows untouched until the last step.
The workpackages
PR 1 — Nix devshell (Linux + macOS) + Cargo
bindepsrefactor + unit testscrates/openshell-driver-vm/Cargo.tomldeclaresopenshell-sandboxas a build dependency withartifact = "bin".build.rsreadsCARGO_BIN_FILE_OPENSHELL_SANDBOXinstead of locating a pre-compressed file inOPENSHELL_VM_RUNTIME_COMPRESSED_DIR. The supervisor stub is removed andmise run vm:supervisoris no longer part of the build path; cargo produces the supervisor as part of building the VM driver. This relies on Cargo's unstableartifact-dependenciesfeature, which is gated to nightly.Native libs (
libkrun.so,libkrunfw.so.5,gvproxy) come from Nix derivations on both Linux and macOS. Darwin support for thelibkrunbuild is not yet available in the flake and is planned work as part of this PR.Exit:
nix develop -c cargo test --workspace --libgreen on Linux + macOS.PR 2 — E2E and integration tests under
nix flake checkAdd
kubectl,helm,k3d,skaffold,python313,uv, and supporting utilities (socat,jq,zstd,openssh). Bring integration and e2e coverage undernix flake checkso a single command covers unit, integration, and e2e on Linux. Where the currente2e/shell scripts can be expressed as Nix checks they are migrated; remaining scripts run from insidenix develop.Migration scope is open: the boundary between checks expressed in Nix and retained shell scripts is determined during the PR, and is expected to be the largest body of work in this sequence.
Exit:
nix flake checkgreen on Linux, covering unit tests, integration tests, and the e2e suite.PR 3 — Formatting and lint
Expand
treefmt-nixto coverrustfmt,ruff format,shfmt,prettier, on top ofnixfmt. Wireclippy,ruff check,markdownlint-cli2, and the license-header script intonix flake check. Extendscripts/update_license_headers.pyto handle.nix.nix fmtandnix flake checkbecome the entry points.Exit:
nix flake checkcovers the same checksmise run pre-commitruns today.PR 4 — Build all release-binary artifacts via Nix
Add
crane. Per-binary derivations foropenshell-cli,openshell-server,openshell-sandbox,openshell-driver-vm,openshell-router,openshell-tui. Python wheel via maturin under crane (oruv2nixfor fully Nix-resolved Python deps). Cross-compile tox86_64-linux,aarch64-linux,aarch64-darwin.Out of scope:
.deb/.rpm/ docker images / Helm chart packaging — downstream of the binaries; separate PR if needed.Exit: every binary CI currently ships is reproducible via
nix build .#<name>.PR 5 — Replace CI, decommission mise
New GitHub Actions workflow using a Nix installer + a store cache. Lint/test/build jobs run via
nix flake checkandnix build. Shadow alongside the existing mise CI for ~a sprint. Once stable: deletemise.toml,mise.lock,Dockerfile.ci; sweep references intasks/,.agents/skills/,CONTRIBUTING.md,AGENTS.md.Exit: CI green on
mainwith mise removed.Open decisions
-
Toolchain scope (PR 1) —
bindepsrequires nightly, soopenshell-driver-vmneeds a nightly toolchain regardless. Throughrust-overlay, a nightly toolchain is exposed the same way as the current stable pin (a one-line change inflake.nix/rust-toolchain.toml), so this is a preference question rather than a feasibility one:- Whole workspace on nightly — one
cargo buildcovers everything with a single toolchain. - Nightly scoped to
openshell-driver-vmvia a per-craterust-toolchain.toml— the rest of the workspace stays on the current stable pin.
Not settled.
- Whole workspace on nightly — one
-
CI cache (PR 5) — hosted, GHA-scoped, or self-hosted?
Next step
PR 1 is in progress.
-
- changed the title
[-]Evaluate Nix for DX and Builds[/-][+]build: evaluate Nix to improve dx and builds[/+]on May 15, 2026 Given new constraints on the openshell build matrix. Nix seems to be, at this time, not a good candidate as a build system successor for OpenShell.
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsDone
We've had requests from the community to use tools such as nix. Evaluate nix and other tools for improving build infra and DX.
Goal is to