The pin was a week old: the hygiene shell had the nightly of 2026-10-27. The nightly of
2026-11-04 formats the whole tree unchanged. Every other tool of the shell was already the latest
release (actionlint 1.7.12, shellcheck 0.11.0, cargo-deny 0.20.2, ripgrep 15.2.0, jq 1.8.2, cargo 1.99.1).
One flake.nix and one flake.lock replace the root flake that re-exported two nested flakes.
The inputs are one nixpkgs (the revision the KDE flake was locked to, f05535a0: the VM suites
run against its Plasma and KWin 6.8.2), one crane, rust-overlay (19ecdd08, rustc 1.99.1),
flake-parts, treefmt-nix and git-hooks-nix, all the KDE flake revisions, plus asc. A second
nixpkgs, nixpkgs-x86_64-darwin (16c7794d, the macOS flake pin), serves the x86_64-darwin
outputs only: evaluating that system with the unified pin throws (nixpkgs 26.11 dropped it).
Layout: nix/common.nix (systems, pkgs, treefmt, pre-commit, dev shells default and native,
default overlay), nix/lib.nix, nix/workspace-src.nix (one source per platform from the one Cargo
workspace: the platform members, its files of the shared crates told apart by name, the data
files, and stubs for the other members, which cargo needs), nix/{windows,linux,macos}/
{build,flake-module}.nix. The dependency derivations use a manifests-only dummy source, a plain
path, so crane reads nothing built at evaluation and the Darwin outputs evaluate on Linux.
Names: unprefixed outputs are the native build (Linux: KDE; Darwin: macOS); Windows cross
outputs are windows-*; checks are windows-*, linux-*, macos-* and vm-NAME; table in docs/dev/flake.md
(next revision). One deny.toml, one format-all and one version (workspace) are used by all.
PLACEHOLDER for the agent that owns the check sets: the checks that evaluate a NixOS system
or a VM (vm-*, linux-nixos-module-eval, linux-plasma-guests-eval, linux-run-kde*) are
legacyPackages.<system>.heavyChecks.<name>, not checks, because evaluating them needs more
memory than nix flake check --all-systems can use. The Plasma guests got a stub root file system
and boot loader (mkDefault, replaced by their vmVariant) so that nix flake check can evaluate
their toplevel.
Verified: nix flake check --no-build --all-systems passes (42 s, rc 0); nix flake check
--no-build passes. Not verified: any build (next revisions record them).
The first darwin build of the root flake failed in komorebi-workspace-deps:
rustc 1.92.0 is not supported by sysinfo@0.39.6 (requires rustc 1.95).
rust-toolchain.toml says channel = stable, and kfm-rust-overlay was pinned
to 1d3f83ba (January 2026), whose stable is 1.92.0, while the unified lock
now has sysinfo 0.39/0.40 and parking_lot 0.13 (rust-version 1.95, the
highest in the macOS and the KDE closures by cargo metadata).
kfm-rust-overlay (flake.nix, flake.lock, and the pin in
komorebi-for-mac/flake.lock) now uses 19ecdd08, the revision the root
flake's own rust-overlay and kfde-rust-overlay lock; its stable is 1.99.1.
kfm-nixpkgs and every other input are unchanged.
Verified (nix eval of drvPath, throwaway git copy before/after): the
Windows deps, clippy and nextest, and the kfde deps, clippy, nextest and
VM suite stacks are identical; kfm deny, fmt and toml-fmt change (the
toolchain). rust-bin.stable.latest version evaluated: 1.99.1 at the new
rev, 1.92.0 at the old one. Not verified: the darwin clippy, nextest and
deps drvPaths cannot be evaluated on this Linux host (the stub source is a
derivation the host cannot build); no build run.
The root flake got the code of komorebi-for-kde and komorebi-for-mac through two locked path inputs (kfde, kfm), so the root flake.lock pinned the content of those directories and needed 'nix flake update kfde kfm' after any edit under them; a stale pin gave 'attribute lib missing'.
Now the root imports komorebi-for-kde/flake.nix and komorebi-for-mac/flake.nix as plain files and calls their outputs/lib.mkOutputs with inputs declared in the root under the names kfde-* and kfm-* (nixpkgs, nixpkgs-lib, flake-compat, flake-parts, crane, rust-overlay, treefmt-nix, git-hooks-nix, and gitignore for kfm), pinned by revision in the URL to exactly the revisions of each nested flake.lock, with the same follows structure. The nested flakes are unchanged and still have their own locks. The kfde and kfm nodes are gone from flake.lock. When a nested flake.lock is bumped, update the revisions of the matching kfde-*/kfm-* inputs by hand.
Verified (tier 2): derivation paths unchanged before and after for kfde fmt, deny, nextest, schema-fresh, the Windows workspace clippy check, kfde-komorebic and kfm-komorebic (aarch64-darwin, eval only); every narHash of the nested locks is present in the root lock; nix flake check --no-build passes on x86_64-linux; nixosModules, overlays, darwinModules evaluate; kfde-vm has 34 suites.
The root flake.lock pins the content of komorebi-for-kde and komorebi-for-mac (D14 of the flake phase 2 work: the root passes its own self to the nested mkOutputs, and the lock records the nested directories). Their trees changed with the step 1 crate and the crates directory in the source filter, so the pins are updated with nix flake update kfde kfm. Only flake.lock changes.
The root flake no longer re-exports the nested flakes' own outputs. It keeps them as inputs for their pinned nixpkgs, crane and rust-overlay (inputs.<name>.inputs), but calls their lib.mkOutputs with the whole repository (self) as the source, a nested self carrying the root rev, dirtyRev and inputs, and the tree's directory, then re-exports packages, checks (without vm-*), legacyPackages.kfde-vm, nixosModules, overlays and darwinModules from those. flake.lock is updated for the changed nested flakes: the lock pins their content, so it needs 'nix flake update kfde kfm' whenever a file under komorebi-for-kde or komorebi-for-mac changes.
Verified (Linux, x86_64): nix build -L of packages.kfde-komorebic and kfde-komorebi succeed and both binaries run with --help (exit 0); checks kfde-schema-fresh, nix-options-validation, keybindings-fixtures, komorebi-bridge-js, nixos-module-eval, plasma-guests-eval, run-kde-dry-run, run-kde-doctor, komorebi-workspace-fmt, -deny and -nextest build; kfde-komorebi-workspace-toml-fmt FAILS because komorebi-for-kde/Cargo.toml itself is not taplo-formatted (same result running taplo on the file directly; not caused by this change). nix eval of aarch64-darwin kfm-komorebic and kfm-komorebi drvPath print .drv paths (evaluated, not built). Windows clippy and default drvPaths are identical to those before this revision. nix flake check --no-build passes for x86_64-linux. Not verified: any darwin build, kfde clippy/doc, the VM suites.
Phase 1 of A3b. The root flake imports the nested flakes' lib.mkOutputs with the whole repository as source and re-exports packages, checks (without vm-*), nixosModules, overlays and darwinModules with kfde-/kfm- prefixes. Windows outputs are untouched. Verified: the KDE package builds; the macOS package evaluates (not built).
I was getting really tired of having to switch between display inputs to
different platform-specific machines to be able to make and test changes
on komorebi for Windows and komorebi for Mac.
With this commit, the `flake.nix` provides a Nix devShell and crane
build for users to make and validate changes with `cargo check`, `cargo
clippy` and `cargo build` with the Windows MSVC toolchain on Linux and
macOS.
LGUG2Z