fix: use pixi-compatible variable syntax in Windows tasks

[miyanyan]

What

This updates the Windows pixi task/env definitions in:

• cuda_pathfinder/pixi.toml
• cuda_bindings/pixi.toml
• cuda_core/pixi.toml

It replaces cmd.exe-style %VAR% references with $VAR syntax in Windows-specific pixi task and environment entries.

Why

pixi run executes tasks via deno_task_shell, not cmd.exe or PowerShell.

Because of that, values like %PIXI_PROJECT_ROOT% are passed through literally instead of being expanded on Windows. That causes commands to fail with errors like:

PS D:\github\miyanyan\cuda-python\cuda_pathfinder> pixi run test
Pixi task (test in default): pytest %PIXI_PROJECT_ROOT%                                                                                          
============================================================= test session starts ============================================================== 
platform win32 -- Python 3.14.2, pytest-9.0.2, pluggy-1.6.0
Using --randomly-seed=822857797
rootdir: D:\github\miyanyan\cuda-python\cuda_pathfinder
configfile: pyproject.toml
plugins: mock-3.15.1, randomly-3.15.0, repeat-0.9.4
collected 0 items                                                                                                                                

============================================================ no tests ran in 0.02s ============================================================= 
ERROR: file or directory not found: %PIXI_PROJECT_ROOT%

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[mdboom]

Any thoughts about how we could test this so this doesn't happen again?

[miyanyan]

Any thoughts about how we could test this so this doesn't happen again?

1. Add a lightweight static check for pixi.toml files.
   Since the current CI does not exercise the pixi task definitions themselves, the simplest protection would be to reject cmd.exe-style %VAR% references in pixi task/env entries. That would have caught this issue directly.

2. Add a small dedicated pixi smoke test in CI.
   This would explicitly exercise the pixi path on Windows, for example by running a few manifest-level commands or dry-runs. That would give us runtime coverage for pixi task syntax, but it is a slightly bigger CI change.

3. Add pixi-based CI coverage since pixi is already a supported workflow.
   If we expect contributors and users to rely on pixi, it seems reasonable for CI to exercise that path as well.

From what I can tell, the current CI mainly validates the wheel build/test flow (pip install + pytest), so this pixi-specific regression was outside its coverage.

[cpcloud]

Blocking this until there's a test for it seems wrong. Let's just create a follow up to address it.

[rwgk]

Blocking this until there's a test for it seems wrong.

I agree.

Let's just create a follow up to address it.

Sounds good to me.

[rwgk]

/ok to test

[copy-pr-bot]

/ok to test

@rwgk, there was an error processing your request: E1

See the following link for more information: https://docs.gha-runners.nvidia.com/cpr/e/1/

[rwgk]

/ok to test 0745279

[github-actions]

Doc Preview CI
🚀 View preview at https://nvidia.github.io/cuda-python/pr-preview/pr-1793/
https://nvidia.github.io/cuda-python/pr-preview/pr-1793/cuda-core/
https://nvidia.github.io/cuda-python/pr-preview/pr-1793/cuda-bindings/
https://nvidia.github.io/cuda-python/pr-preview/pr-1793/cuda-pathfinder/
Preview will be ready when the GitHub Pages deployment is complete.

[rwgk]

The cuSparseLt errors will most likely disappear when updating the branch. I'll try that now.

[rwgk]

/ok to test 3d01d6a