feat(nix): ❄️ add a flake with package, app and dev shell

[Panadestein]

🤖 AI text below 🤖

Adds a Nix flake so Nix/NixOS users can build and hack on monoprop without installing the C++ toolchain, hwloc, Boost or MPI by hand.

Outputs

Command	What it gives you
nix develop	dev shell: GCC 15, CMake, Ninja, Boost, hwloc, Open MPI, uv, just, Node.js, clang-tools, gdb, lcov, doxygen
nix build .#monoprop	the Python package, without MPI
nix build .#monoprop-mpi	the same package with monoprop_ENABLE_MPI=ON
nix run	a Python interpreter with monoprop importable

Inside nix develop, the existing uv sync and just workflows apply unchanged. The shell sets UV_PYTHON_PREFERENCE=only-system (uv's managed interpreters expect a loader NixOS does not provide, and [tool.uv] pins only-managed) and LD_LIBRARY_PATH so manylinux wheels resolve libstdc++.

Deviations from the uv build

All three are in nix/monoprop.nix and documented in the building guide:

• C++ unit tests are off — they resolve msgpack-cxx through a CPM git fetch that the build sandbox denies. Build them from the dev shell instead.
• monoprop_ENABLE_ARCH_FLAGS is off, since a store path may be substituted onto a machine other than the one that built it. .override { enableArchFlags = true; } restores -march=native.
• The version is pinned, because setuptools-scm cannot read git metadata inside the sandbox. It needs bumping alongside the release tag.

Notes for reviewers

• nixpkgs ships scikit-build-core 1.0.2 while [build-system] requires asks for >=1.0.3, so the flake overrides it with the 1.0.3 PyPI sdist. That override should be dropped once nixpkgs catches up.
• mpi4py is listed in [build-system] requires unconditionally, so it is a build input even for the non-MPI package.
• tools/generate-dispatch.py reads .github/license-header.txt during cmake --install, but .github is in sdist.exclude. The flake works around it by including that one file in the source set; an sdist-based install would presumably hit the same failure.

Validation

On x86_64-linux: nix build .#monoprop and .#monoprop-mpi both compile and pass the import check, nix flake check passes, nix run evaluates a MajoranaOperator, and uv sync inside nix develop builds the bindings against the Nix toolchain. Darwin and aarch64-linux are exposed via flake-utils.lib.eachDefaultSystem but untested.

[github-actions]

Docs preview: https://pr-241.monoprop-docs.pages.dev

[Panadestein]

Why not uv2nix?

I evaluated uv2nix for this flake and decided against it. uv2nix turns uv.lock into the nix dependency graph, so nix and uv can't drift. That's valuable when the lock file describes the hard part of your build, but here it doesn't:

• uv doesn't lock build backends (astral-sh/uv#5190). uv.lock contains no nanobind, scikit-build-core or setuptools-scm, so the entire C++ build (toolchain, boost/hwloc/MPI, the nanobind CMake dir, the arch-flag and unit-test toggles) would still be handwritten
• The runtime closure is trivial: numpy and msgpack, both in nixpkgs at the locked versions. No dependency problem to solve.
• It would degrade the dev shell. uv sync inside nix develop gives an incremental C++ build tree; a nix-built venv replaces fast ninja rebuilds with a full derivation rebuild per edit.