CI: Test sdist completeness for all user-facing packages on Linux and Windows

[cpcloud]

Summary

Adds a CI job that builds an sdist then a wheel-from-sdist for each of the
4 user-facing packages (cuda_pathfinder, cuda_python, cuda_bindings,
cuda_core) on both Linux and Windows. This catches MANIFEST.in /
package-data drift regressions (as previously slipped through in #1588) and
now also catches platform-gated source drift.

Why both platforms

cuda_bindings/build_hooks.py picks different *.pyx variants at build
time depending on sys.platform (*_linux.pyx vs *_windows.pyx), so a
Linux-only sdist completeness test cannot prove that the sdist ships the
Windows sources required to build a wheel-from-sdist on Windows.

Running the same build chain on Windows in CI closes that gap for
cuda_bindings (which also forces cuda_core to exercise the same
wheel-from-sdist code path, since cuda_core's wheel build requires a
cuda_bindings wheel).

Layout

• .github/workflows/test-sdist-linux.yml: Linux sdist job (self-hosted
  runner, sccache + proxy cache, same CTK fetch as build-wheel.yml).
• .github/workflows/test-sdist-windows.yml: Windows sibling
  (windows-2022 + ilammy/msvc-dev-cmd, no sccache or proxy cache, same
  CTK fetch on win-64).
• ci.yml wires both as test-sdist-linux / test-sdist-windows, gated by
  should-skip and doc-only, and both are included in the checks
  aggregator so either failing blocks merge.

Scope

Pure-Python packages (cuda_pathfinder, cuda_python) don't depend on
platform-gated sources, so the Windows job is primarily for cuda_bindings
and cuda_core. The pure-Python builds are included on Windows too because
they are essentially free and keep the two workflows symmetric.

Closes #1599.

[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.