Inspected the current named-platform syntax in ~/work/histo/pyproject.toml and its version 7 lockfile.
Created chore/pixi-cuda-platform from origin/unify-vits in an independent worktree.
Replaced the deprecated ve2e per-feature CUDA system requirement with the named linux-64-cuda platform declaring CUDA 12.2.
Bound the CPU-only environments to plain linux-64, which preserves their old platform scope and avoids adding unrelated CUDA-platform solutions to the lockfile.
Regenerated and checked pixi.lock; Pixi reported it was already current because the existing lock encoded the equivalent synthetic __cuda=12.2 platform.
Validated the TOML, lock consistency, platform-to-environment mapping, and clean diff. Opened ve2e PR #424 against unify-vits.
Lessons Learned: Pitfalls
A direct migration that only follows Pixi’s per-feature example makes the named CUDA platform workspace-wide. On this repository, an unconstrained pixi lock then adds full CUDA-platform solutions for the CPU default and dev environments, creating thousands of unrelated lockfile lines.
The user’s Pixi config has a separate deprecated tls-root-certs = "all" warning. Running validation with a clean temporary HOME isolates the target system-requirements warning without changing user config.
Lessons Learned: Improvements
Pixi migration guidance should mention that environments which must remain CPU-only can declare platforms = ["linux-64"]; feature platform sets are intersected with inline environment platform sets.
When a version 7 lockfile already contains the synthetic virtual-package platform, pixi lock may correctly produce no diff after the manifest migration.
