Setup cuda-python integration tests

[rparolin]

Motivation

The cuda-python monorepo contains four published packages with an explicit dependency graph:

cuda_pathfinder   → (no internal deps)
cuda_bindings     → cuda_pathfinder
cuda_core         → cuda_pathfinder, cuda_bindings
cuda_python       → cuda_bindings (meta package)

Today, CI tests each sub-package in isolation against its own unit/functional tests (see ci/tools/run-tests). What we lack are integration tests that exercise cross-package interactions and end-to-end workflows using the published packages together — the way a real user would install and use them.

Gaps in current testing

1. No cross-package compatibility tests — cuda.core internally calls cuda.bindings APIs (e.g., driver/runtime bindings). Today each package is tested in isolation, so a breaking change in cuda.bindings (changed signature, renamed enum, different return type) could silently break cuda.core without CI catching it. Integration tests would install both built wheels together and verify cuda.core operations that depend on cuda.bindings still work end-to-end.

2. No end-to-end user workflow tests — We don't test realistic user scenarios like:

   • pip install cuda-python[cu13] → import all sub-packages → run a simple kernel
   • Install cuda-core from PyPI wheel → use cuda.core.Program to compile and launch a kernel
   • Install from source (editable mode) → run tests

3. No downstream consumer smoke tests — We don't validate that packages like CuPy, numba-cuda, or Triton can still import and use cuda-python APIs after a change.

4. No pathfinder ↔ bindings ↔ core version-matrix tests — The backport-branch mechanism (12.9.x) tests old bindings with new core, but we don't systematically test version compatibility boundaries (e.g., cuda-pathfinder 1.4.x vs 1.5.x with cuda-bindings 13.x).

Proposed scope

Phase 1: Cross-package integration tests (in-repo)

• Add a new top-level tests/integration/ directory (or ci/integration-tests/)
• Tests install the built wheels from CI artifacts (same as current test jobs) but exercise cross-package scenarios:
  • Import chain: cuda.pathfinder → cuda.bindings → cuda.core → cuda.python
  • Compile-and-launch: use cuda.core APIs that internally call cuda.bindings to compile a trivial kernel and launch it
  • Pathfinder resolution: verify cuda.pathfinder correctly discovers CTK components that cuda.bindings and cuda.core need
  • Version consistency: all installed sub-packages report compatible versions
• Wire into CI as a new step in test-wheel-linux.yml / test-wheel-windows.yml that runs after individual module tests pass

Phase 2: End-to-end user scenario tests

• Simulate pip install cuda-python[cu13] from scratch in a clean venv
• Simulate editable installs (pip install -e .) and verify tests pass
• Test with both local CTK and wheel-based CTK

Phase 3: Downstream consumer smoke tests

• Minimal import/smoke tests for key consumers (CuPy, numba-cuda)
• Can run on a schedule (nightly) rather than per-PR to limit CI cost