pixi 0.71 breaks build-backend resolution — pixi-build-cmake <=0.3.8 cap too low (recurring; all pixi-build repos)

[joshkamm]

Summary

Installing with pixi 0.71.0 fails at dependency resolution, before any compilation:

Cannot solve the request because of: pixi-build-cmake >=0.3.6,<=0.3.8 cannot be installed:
  ├─ 0.3.7 | 0.3.8 require pixi-build-api-version >=4,<5  → no candidates
  └─ 0.3.6        requires pixi-build-api-version >=2,<3  → no candidates

pixi 0.71 provides a build-API version that none of the pinned backends (0.3.6–0.3.8) satisfy, and the <=0.3.8 upper cap stops pixi from selecting a newer backend that would.

Confirmed reproduction (Perlmutter login node)

• pixi 0.71.0 → fails at the solve above.
• pixi 0.70.0 → resolves pixi-build-cmake@0.3.8, negotiates API v4, builds normally (SlaterGPU compiles fully, libcint found via conda-forge).

This is the recurring tax of the bounded-pin strategy

We pin the build backend on purpose — backend/tooling updates have broken our builds several times:

• Fix CI after broken from new cmake release #50 (closes Debug CI #44) — CMake 4.1.0+ broke CUDA detection; added a version warning + pin.
• ZimmermanGroup/ZEST#28 — pixi-build-cmake adoption saga (HPC/glibc issues, backend-channel version sensitivity).
• Support multiple pixi versions via build backend version range #71 / ZimmermanGroup/ZEST#64 — pixi 0.63 bumped the build-API v2→v4, breaking the old ==0.3.4 pin; fixed by moving to the range >=0.3.6,<=0.3.8.

pixi 0.71 is the next instance: this time the upper cap of that range is what breaks.

Blast radius — all four repos share the identical pin

pixi-build-cmake = ">=0.3.6,<=0.3.8", requires-pixi = ">=0.60.0":

• ZimmermanGroup/SlaterGPU
• ZimmermanGroup/ZEST (pulls SlaterGPU as a source dependency)
• ZimmermanGroup/XCtera (pulls SlaterGPU as a source dependency)
• ZimmermanGroup/molecularGSM

A coordinated bump is needed; ZEST/XCtera also need SlaterGPU bumped because they build it from source.

Proposed fix — keep the bounded pin, bump the cap to a tested version

We should not drop the upper cap (history shows backend updates do break us). Instead:

1. Identify the newest pixi-build-cmake that negotiates with pixi 0.71's build-API version (likely 0.3.9+/0.4.x).
2. Verify a clean pixi install on pixi 0.71 (and confirm a still-supported floor on an older pixi).
3. Bump all four repos to >=0.3.6,<=<new tested version> (keeping a bounded range), updating requires-pixi only if a higher floor is actually required.

Reducing the future maintenance burden

• The monthly use-latest-pixi CI added in Support multiple pixi versions via build backend version range #71 is meant to catch exactly this — confirm whether it already flagged 0.71, and treat its failure as the trigger to bump the cap (turning a user-facing break into a scheduled maintenance task).
• Consider documenting the bump procedure in one place so the four repos don't drift; related: Declare run-exports to consolidate downstream consumers' duplicate pixi.toml entries #89 (run-exports), though the build-backend pin is per-package build config and can't be inherited like a runtime dep.

Context

• Surfaced while doing the local build verification for the exact-4c work (ZimmermanGroup/ZEST#99).

[joshkamm]

Root cause (confirmed) + coordinated fix opened

What pixi 0.71 actually does

pixi 0.71 negotiates build-API version 5. Verified empirically with a clean pixi install of SlaterGPU on Perlmutter:

pixi	backend resolved	API negotiated
0.71.0	pixi-build-cmake@0.4.2	5
0.70.0	pixi-build-cmake@0.3.14	4

(Confirmed against the conda-meta records in the backend cache: pixi-build-cmake-0.4.2 ships pixi-build-api-version-5; 0.3.14 ships pixi-build-api-version-4.)

The old >=0.3.6,<=0.3.8 cap allowed only v2/v4 backends, so under 0.71 the solve had no API-compatible candidate — failing before any compile, exactly as reported.

Why a single bounded range works for both pixi versions

pixi-build-api-version is itself a dependency in the solve, so the resolver picks the newest backend in range whose API the running pixi can negotiate. A range that spans both the v4 and v5 backends therefore self-selects:

• >=0.3.6,<=0.4.2 → 0.71 picks 0.4.2 (v5), 0.70 picks 0.3.14 (v4).

This keeps the bounded-pin policy intact (we are not dropping the cap — backend updates have bitten us before: #50, #71/ZEST#64). We just move the cap to a tested known-good version, 0.4.2.

requires-pixi

Left at >=0.60.0. The widened range only adds backward compatibility (it still includes v2/v3 backends via 0.3.6), so no floor bump is needed.

Coordinated PRs (identical one-line bump)

• SlaterGPU: Bump pixi-build-cmake cap to 0.4.2 for pixi 0.71 (#96) #97
• ZEST: ZimmermanGroup/ZEST#100
• XCtera: ZimmermanGroup/XCtera#17
• molecularGSM: Bump pixi-build-cmake cap to 0.4.2 for pixi 0.71 (SlaterGPU#96) molecularGSM#53

ZEST and XCtera build SlaterGPU from source, so they additionally need #97 merged for a full pixi-0.71 build.

Note on the build itself

On the Perlmutter login node the build proceeds past negotiation/CMake-configure and then hits a pre-existing cublas_v2.h-not-found error — identical under both 0.70 and 0.71, so it is a login-node CUDA-env issue, not introduced by this change. The CI GPU runner builds fine.

CI early-warning (the monthly use-latest-pixi job from #71)

It has not flagged 0.71 yet, purely due to timing: pixi 0.71.0 released 2026-06-24, the last scheduled run was 2026-06-19 (pixi 0.70.x → green), and the next monthly run is 2026-07-01. With the current pin that run would be the first to catch this; if we merge the bump beforehand, that run instead validates it against latest pixi. The mechanism is working as designed — no rewiring required.

Suggested small enhancement: add workflow_dispatch (with a use-latest-pixi boolean input) to ci.yml so maintainers can validate a cap bump against the latest pixi on demand, instead of waiting for the 1st of the month. Happy to fold this into #97 if wanted.

[joshkamm]

Reopening — #97 auto-closed this via a "Fixes #96" keyword, but this issue covers all four repos and shouldn't close until the last one lands.

Status (2026-07-01):

• ✅ Merged to main: SlaterGPU Bump pixi-build-cmake cap to 0.4.2 for pixi 0.71 (#96) #97, ZimmermanGroup/ZEST#100, ZimmermanGroup/XCtera#17 (cap → >=0.3.6,<=0.4.2).
• ⏳ Open: Bump pixi-build-cmake cap to 0.4.2 for pixi 0.71 (SlaterGPU#96) molecularGSM#53 — the cap fix is correct and the build/solve passes, but CI is red on a pre-existing, unrelated libmkl_intel_lp64.so.3 runtime error. Blocked on that, not on this change.

Remaining TODO:

1. Open a separate issue for the molecularGSM MKL runtime failure, fix it, then merge #53 → then close this issue.
2. CI validation against real pixi 0.71 on the merged code is still pending: today's scheduled use-latest-pixi run fired at 00:37 UTC on the old main (a7f971f) and failed (early-warning working); the fix (06e20e1) hasn't had a latest-pixi run, and re-running replays the old SHA. Next natural signal is the 2026-08-01 cron. Proposed fix: add workflow_dispatch (+ use-latest-pixi input) to ci.yml so the latest-pixi path can be triggered on demand against current main.

(Fix already verified locally: pixi 0.71 → pixi-build-cmake@0.4.2, API v5; 0.70 → 0.3.14, API v4.)