René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Make pixi cuda-version pins track ci/versions.yml to prevent toolkit-version drift","articleBody":"## Problem\n\nThe canonical CUDA build version lives in `ci/versions.yml` (`cuda.build.version`), and the generated Cython bindings carry a `# generated with version X` stamp. But the local `pixi run test` path pins CUDA independently via `cuda-version` in `cuda_bindings/pixi.toml` and `cuda_core/pixi.toml` (`[workspace.build-variants]` + `[feature.cu13.dependencies]`).\n\nThese drifted: #2139 regenerated the bindings to 13.3 but left the pixi pins at 13.2, which silently broke `pixi run test` while CI stayed green (see #2182, fixed by #2180). This will recur on the next CUDA bump.\n\n## Proposal\n\nHave the pixi `cuda-version` pins derive from / stay in lockstep with `ci/versions.yml` (e.g. a check or a generation step), so a toolkit bump can't leave the local test env behind.\n\n## Related latent weakness\n\nWhile diagnosing #2182, two local caches did **not** invalidate when the CUDA header version changed underneath them, producing confusing errors:\n- the pyclibrary parser cache (`CUDA_PYTHON_PARSER_CACHING=1` → `cache_driver`/`cache_runtime`) regenerated `driver.pyx` referencing a struct member the new 13.3 header had dropped;\n- setuptools `build_ext` left a stale compiled cython-test `.so` (a `size changed` binary-incompat error).\n\nBoth are gitignored local artifacts (absent on a clean checkout), but worth considering whether a CUDA-version change should invalidate them.\n\n🤖 Filed with [Claude Code](https://claude.com/claude-code)","author":{"url":"https://github.com/rparolin","@type":"Person","name":"rparolin"},"datePublished":"2026-06-09T06:50:21Z","url":"https://github.com/NVIDIA/cuda-python/issues/2183"}