Skip to content

Support multiple pixi versions via build backend version range#71

Merged
DuttaS12 merged 4 commits intomainfrom
pixi-063-compatibility
Feb 24, 2026
Merged

Support multiple pixi versions via build backend version range#71
DuttaS12 merged 4 commits intomainfrom
pixi-063-compatibility

Conversation

@joshkamm
Copy link
Member

@joshkamm joshkamm commented Jan 22, 2026

Summary

  • Changes pixi-build-cmake from ==0.3.4 to >=0.3.6,<=0.3.8, allowing pixi to auto-select the correct backend API version
  • Bumps requires-pixi from >=0.54 to >=0.60.0
  • Updates CI to extract minimum pixi version from pixi.toml instead of hardcoding v0.54.0
  • Adds monthly scheduled CI builds to test against latest pixi

Context

Users installing with pixi >= 0.63 (e.g. fresh installs on Perlmutter) hit a "could not initialize the build-backend" error because pixi-build-cmake==0.3.4 only supports build API v2, while pixi 0.63+ requires API v4. Instead of pinning to the new version (which would break older pixi), we use a version range so pixi resolves the compatible backend automatically. This matches the approach used in molecularGSM.

Note: A corresponding ZEST PR will follow once this is merged, since ZEST also pins ==0.3.4 and needs the same update (both for its own build and because it pulls SlaterGPU as a source dependency).

Test plan

  • SlaterGPU pixi install succeeds on pixi 0.62.2
  • SlaterGPU pixi install succeeds on pixi 0.63.2
  • ZEST pixi run test-slater passes with this SlaterGPU as local path dependency on pixi 0.63.2 (CI: -1.16064818)
  • CI passes on GitHub-provided GPU runner"

pixi-build-cmake version changes:
- 0.3.4 requires build API v2 (pixi 0.54-0.62)
- 0.3.8 requires build API v4 (pixi 0.63+)

This change is required for ZEST to use SlaterGPU as a source dependency
with pixi 0.63+.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
@joshkamm
Copy link
Member Author

joshkamm commented Feb 6, 2026

I figured out in the molecularGSM repo how to configure for multiple potential backend versions and let pixi decide which is compatible with pixi's own version. I should do something analogous here

joshkamm and others added 3 commits February 23, 2026 15:10
Instead of pinning ==0.3.8 (which requires pixi >=0.63), use the range
>=0.3.6,<=0.3.8 so pixi automatically selects the correct backend API
version for the user's installed pixi. This matches the approach used
in molecularGSM and avoids forcing all collaborators to upgrade pixi
simultaneously.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Extract the minimum pixi version from requires-pixi in pixi.toml
instead of hardcoding v0.54.0. Regular builds test against the minimum
supported version; monthly scheduled builds test against the latest
pixi to catch regressions early. Also scope push/PR triggers to the
main branch.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@joshkamm joshkamm changed the title Update pixi-build-cmake to 0.3.8 for pixi 0.63+ compatibility Support multiple pixi versions via build backend version range Feb 23, 2026
@joshkamm joshkamm requested a review from DuttaS12 February 23, 2026 21:09
@joshkamm
Copy link
Member Author

cc @piwonis @DuttaS12 — This PR should fix the "could not initialize the build-backend" error you both ran into when installing with a newer pixi version. Instead of pinning to a single pixi-build-cmake version, we now use a version range (>=0.3.6,<=0.3.8) that works with both older and newer pixi.

A corresponding ZEST PR with the same change will follow once this is merged.

@joshkamm joshkamm self-assigned this Feb 23, 2026
@DuttaS12 DuttaS12 merged commit 8bc5570 into main Feb 24, 2026
1 check passed
@joshkamm joshkamm deleted the pixi-063-compatibility branch February 24, 2026 03:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants