Repository navigation
mcpx: decide how downstream flakes consume mcpx (sub-flake or the root flake) #308
Description
Problem
dezren39/nix vendors a copy of pkgs/mcpx because it has no cheap way to take mcpx from this repo. That copy has drifted: 29 files differ today, and each side holds fixes the other lacks (see dezren39/nix, the issue that removes the copy). This repo is the primary source for mcpx, so the vendored copy should go. First there has to be a way to consume mcpx from here.
What exists
- The root flake already exposes
packages.<system>.mcpxandapps.<system>.mcpx(lib/default.nix,make-root-apps), built with a plaincallPackage ../pkgs/mcpx/package.nix { }. overlays.mcpxandoverlays.defaultalso providepkgs.mcpx(make-mcpx-overlay).pkgs/idhas its own flake, which is a precedent for a package that downstream users take without the rest of the repo.
What is missing
Adding this repo as a flake input pulls the whole input graph (clan, disko and the NixOS inputs) into the darwin flake's lock file. I have not measured how large that gets, only that the root flake has far more inputs than mcpx needs.
Other points a consumer hits:
package.nixtakesbun-bin ? bun. The darwin flake passes its ownpkgs/bun-bin.- The package is built with
buildGo127Module, so the consumer's nixpkgs needs it. - The darwin build fails its own check phase on takeover tests that only work on Linux. That is the existing issue mcpx: takeover/upgrade/handoff unsupported on darwin; Linux-only tests break the darwin build #237, and it blocks this one on aarch64-darwin.
Options
- A small
pkgs/mcpx/flake.nixwhose only input is nixpkgs, consumed asgithub:developing-today/code?dir=pkgs/mcpx. - Consume the root flake and use
followsto keep the lock small. - Consume
overlays.mcpxfrom the root flake.
Acceptance criteria
- One option is chosen and the reason is written down here.
-
dezren39/nixcan build mcpx from a pinned rev of this repo on aarch64-darwin with no vendored source. - The consumer can override
bun-binor the package pins the one it needs. - CI here builds the package on a darwin runner, or the issue says why it does not.
Activity
dezren39 commentedon Oct 19, 2026
Decision recorded 2026-10-19, from the mcpx dedup work (dezren39/darwin-nix#468): the consumer takes a source-only flake input —
mcpx-src = { url = "github:developing-today/code"; flake = false; }, pinned in the consumer's flake.lock — and calls thepackage.nixthat already lives in this repo:pkgs.callPackage (inputs.mcpx-src + "/pkgs/mcpx/package.nix") { inherit bun-bin; }.Why this over the listed options: it pulls none of this repo's flake input graph into the consumer's lock (the concern option 2 raised), needs no new sub-flake here (option 1), and the derivation file is already byte-identical in both repos — its
src = ./.resolves to its own directory in the pinned source.bun-binstays overridable by the consumer, and the consumer's existing darwin overrideAttrs (code#237's skip list + SOCK_CLOEXEC patch) carries over unchanged because the source layout is identical.Implemented in dezren39/darwin-nix#468 (its PR pins the rev containing code#361, the one test migration the audit found). Remaining from this issue's criteria: aarch64-darwin build verification happens on Drew's Mac — the Linux sandbox can't check it; leaving this issue open for that confirmation.
dezren39 commentedon Oct 26, 2026
Intake review
🤖 Agent note · filed
Partly answered downstream since filing (verified this run): dezren39/nix PR #469 deleted the vendored
pkgs/mcpxcopy and switched that repo to building mcpx from a pinnedmcpx-srcflake input pointing at this repo — in effect the root-flake/input route (the body's options 2/3 family), not apkgs/mcpxsub-flake. The vendored-copy problem the body opens with is therefore solved on the consumer side. What remains open here: recording that choice as this repo's decision (criterion 1), the aarch64-darwin build verification of that pinned input (tracked as dezren39/darwin-nix#471), and the darwin CI question (criterion 4). Not closing — no merged PR in this repo explicitly resolves it.Related: dezren39/darwin-nix#468/#469 (the consumer migration), dezren39/darwin-nix#471 (darwin verification), #237 (darwin takeover tests — the check-phase blocker the body names), developing-today-forks/opencode#82 (the sibling question on the opencode flake).
Notes / risks: acceptance criteria are present — no body edit needed.
Suggested approach: a short decision comment here adopting the pinned-input route as the recorded answer, leaving #471 and #237 as the tracked remainders; close once that comment and the roadmap pointer (code#309) are in place.
dezren39 commentedon Nov 1, 2026
🤖 Agent note · picked up
dezren39 commentedon Nov 1, 2026
🤖 Agent note · done (triage — decision already made and implemented; closing)
The question this issue asked is already answered. The 2026-10-19 comment on this issue records the decision (from the dezren39/darwin-nix#468 dedup work): downstream flakes consume mcpx as a source-only flake input —
mcpx-src = { url = "github:developing-today/code"; flake = false; }— andcallPackagethis repo's existingpkgs/mcpx/package.nixfrom the pinned source. That is neither option 1 (no sub-flake:pkgs/mcpx/on current main has noflake.nix— verified by directory listing today) nor options 2/3 (no root-flake input graph enters the consumer's lock).Acceptance criteria, dispositioned:
pkgs/in dezren39/nix no longer contains mcpx and itsflake.nixreferencesmcpx-src. The aarch64-darwin build verification itself is still owed and is tracked as mcpx: aarch64-darwin build verification still owed for the pinned mcpx-src input (from #469/#468) dezren39/darwin-nix#471 — it can only run on Drew's Mac, per the decision comment.bun-binconsumer-overridable and nix#468 implemented it that way (the consumer's darwin overrideAttrs carried over unchanged).nix buildthe package on a darwin runner: there is no darwin Nix builder in the fleet's CI. What CI does do today (verified in.github/workflows/mcpx.ymlon main): PR jobs cross-compile-check darwin/arm64 from ubuntu (scripts/darwin-compile-check.sh), and the nightly stress job runs the Go suite onmacos-latest. The actual darwin nix build verification is exactly the remainder tracked in mcpx: aarch64-darwin build verification still owed for the pinned mcpx-src input (from #469/#468) dezren39/darwin-nix#471.Closing this issue — the decision + consumer migration it existed to produce are complete; every remainder already has its own tracked home: dezren39/darwin-nix#471 (darwin build verification, Drew's Mac), code#237 (darwin takeover-test check-phase blocker), code#309 (mcpx backlog re-home, still open). No follow-up packet is needed from this triage.
Merge pull request #3345 from developing-today/docs/roadmap-sync-mcpx…