Repository navigation
ci: work around Pixi samples-source lockfile oscillation - #3059
Conversation
|
Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually. Contributors can view more details about this message here. |
|
/ok to test f6387f0 |
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configuration
📒 Files selected for processing (5)
Included review availability: This review used your included allowance. Your plan provides up to 12 included reviews per hour; 11 remain after this review. 📝 SummarySummary by CodeRabbit
WalkthroughThe CI adds a detector for a specific Pixi 0.73.0 lockfile change that removes samples environment source references. The freshness workflow applies a conditional exception to matching changes, while source-build CI uses frozen mode. ChangesPixi Lockfile Exception
Priority: ⬇️ Low Change: Bug fix Merge Risk: ⚪ Minimal · up to The guarded lockfile exception preserves the base comparison, and no actionable merge-blocking issue remains after normal checks.
Comment |
There was a problem hiding this comment.
Is there a pixi issue to watch?
Description
Temporarily unblock Pixi freshness and source-build CI without regenerating the
lockfiles, upgrading Pixi, or letting published wheels replace our local packages.
Why a lockfile refresh cannot fix this
Pixi 0.73.0 checks PyPI requirements that the
samplesenvironment explicitlyexcludes with false-marker overrides. Its repair path then removes the local
Conda source references; a subsequent lock command adds them back. Repeated
refreshes therefore do not converge. The source-build job also fails because
--lockedchecks the whole workspace, including this unrelated environment.The reduced reproducer confirms two upstream defects: override markers are not
honored during freshness traversal, and PyPI-only refreshes drop partial Conda
source records. Both reproduce on Pixi 0.81.0 and source HEAD
38ceaa89ac03649aaaefb919d1e501ca3d074d88; this is distinct from the earlierdependency-ordering problem (Pixi #7000).
See also: Pixi #7215, with the
reduced reproducer, suggested two-part fix, regression tests, and validation logs.
Temporary workaround
PIXI_FROZEN=true, including nested Pixi commands. Itkeeps the committed dependency solution and still builds the checkout's source
packages, without triggering the broken workspace-wide freshness check.
nine
sampleslocal-source references across the three platforms. Everyother lockfile byte must remain identical; manifest overrides, paths, and
source-record definitions must also match.
exactly, and no
pixi.toml,pyproject.toml, or Pixi-version input may change.This exception is therefore limited to the inherited defect, not PR-induced
changes. Recognized cases emit a warning and restore the committed references.
remains strict and does not open a PR for unstable lockfiles.
Validation
detector cases covering exact matches, unrelated changes, and error handling.
fresh;
cuda_corematches the narrowly guarded inherited defect.pass: 1,615 pathfinder tests passed, five skipped, successful bindings/core
imports, and native Cython extension compilation and placement.
passes with the expected warning and the committed lockfile restored.
all 118 executed checks passed, with five intentional skips. One Windows
Python 3.14 / CUDA 13.4.2 / L4 MCDM test was still queued for a runner when
monitoring stopped; its result has not been verified.
scan finds eight pre-existing 404s in unrelated sample READMEs.
Removing the workaround
Once a released Pixi passes repeated lock/check commands on the reproducer and
all CUDA Python workspaces without changing their bytes, remove the detector
and freshness exception and restore
PIXI_LOCKED=true. Also verify thatselective PyPI updates retain local source records. No lockfiles or manifests
are changed by this PR.
Checklist