CI: Test sdist builds for all user-facing packages

[cpcloud]

Summary

• Adds .github/workflows/test-sdist.yml reusable workflow that builds sdist then wheel-from-sdist for all 4 user-facing packages
• Pure Python packages (cuda_pathfinder, cuda_python) built first without CTK
• Cython packages (cuda_bindings, cuda_core) built with sccache + mini CTK, respecting build-dep chain via PIP_FIND_LINKS
• Single matrix point: linux-64, py3.12, one CUDA version (sdist correctness is platform-independent)
• Wired into ci.yml as test-sdist job, gated by should-skip and doc-only, included in checks
• Catches MANIFEST.in / package-data drift regressions from PR Reduce wheel size by excluding source files #1588

Closes #1599

🤖 Generated with Claude Code

[github-actions]

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

[rwgk]

Posting this separately as an optional suggestion. LGTM will be in another comment.

Outcome of a few rounds of prompt/response using Cursor GPT-5.4 Extra High Fast

---

Analysis

I think the current test-sdist.yml setup is probably fine in practice today, because the branch-local setuptools-scm versions are ahead of the currently published compatible releases.

However, PIP_FIND_LINKS alone does not fully encode the intended guarantee. It tells pip where local candidates live, but it does not require build isolation to use those exact local internal wheels. So the job is still somewhat fragile:

• it depends on the current version ordering
• it depends on what is or is not already published
• it could become ambiguous again on a rerun, a backport, or once a newer compatible release exists on PyPI

So I would frame this as a robustness / explicitness issue more than an immediate correctness bug.

The nice part is that I think removing that uncertainty is fairly easy.

Suggestions

1. Best balance: keep build isolation, add exact build constraints

This seems like the best option to me.

Keep the existing pattern:

• build local internal wheels first
• use PIP_FIND_LINKS to point pip at those local wheel directories

But add exact --build-constraint files for the pip wheel ... <sdist.tar.gz> steps.

For cuda.bindings, constrain the local cuda-pathfinder wheel version exactly.

For cuda.core, constrain both:

• the local cuda-bindings wheel version
• the local cuda-pathfinder wheel version

Why this is attractive:

• it preserves build isolation
• it keeps the test meaningfully close to real PEP 517 behavior
• it removes the resolver ambiguity cleanly
• the local wheels have unique +g<sha> versions, so exact constraints should force the branch-local artifacts in practice

2. Stronger but heavier: use --no-index with a fully local wheelhouse

This would remove even more uncertainty:

• local internal wheels come only from the wheelhouse
• third-party build requirements also come only from the wheelhouse

But this is more work, because the wheelhouse would need to contain everything needed for build isolation:

• setuptools
• setuptools-scm
• build
• Cython
• pyclibrary
• and so on

This is probably overkill unless there is a broader goal of making the job network-independent or completely hermetic.

3. Simplest but weaker: disable build isolation

Another option is:

• install the local internal wheels into the job environment first
• then build with --no-build-isolation

This would be easy and deterministic, but it weakens the test. The point of this job seems to be checking sdist/build-backend correctness under something close to normal isolated builds, so I think this is the least attractive option.

Suggested implementation direction

If the goal is just to remove uncertainty without broadening the PR much, I would suggest option 1.

Concretely:

• after building cuda_pathfinder/dist/*.whl, derive its exact version from the wheel filename
• write a small constraints file for the cuda.bindings wheel-from-sdist step
• after building cuda_bindings/dist/*.whl, do the same for cuda.core
• keep the existing PIP_FIND_LINKS
• add --build-constraint <file> to the pip wheel commands

I would focus this only on the pip wheel ... <sdist> steps. That is the part where the cross-package build dependency resolution matters. The python -m build --sdist ... steps are less important for this specific ambiguity.

Small example shape

For cuda.bindings, something conceptually like:

export PIP_FIND_LINKS="$(pwd)/cuda_pathfinder/dist"
python write_constraints.py cuda_pathfinder/dist > cuda_bindings/build-constraints.txt
pip wheel \
  --no-deps \
  --build-constraint cuda_bindings/build-constraints.txt \
  --wheel-dir cuda_bindings/dist \
  cuda_bindings/dist/*.tar.gz

For cuda.core, same idea, but constrain both local internal deps.

Agent hint

If the author wants to hand this to an agent, I would give it these constraints:

• preserve build isolation
• do not switch to --no-build-isolation
• keep PIP_FIND_LINKS
• derive exact versions from the just-built wheel filenames, rather than hardcoding anything
• prefer a tiny inline Python snippet using packaging.utils.parse_wheel_filename(...) to extract versions robustly
• constrain only the wheel-from-sdist steps unless there is a clear reason to widen the scope

That should keep the change small, explicit, and easy to review.

[rwgk]

Looks great.

One small caveat: the new test-sdist job only runs on Linux, so it does not fully prove platform-independent sdist completeness for packages that have platform-specific sources. For example, cuda_bindings/build_hooks.py selects different *_linux.pyx vs *_windows.pyx files, so a missing or stale Windows-only source could still slip through. I think this is still a useful test as-is; I would probably either add a small Windows follow-up job (at least for cuda_bindings, and likely cuda_core too), or keep this PR as-is but make it clear in the PR title and description that this is a Linux-side sdist smoke test rather than a full cross-platform proof.