Distribution and dependency checks

The quality runner includes deptry on src/pipewhy and tools. Its runtime audit rejects missing, unused, transitive-only and misplaced development dependencies. Development CLI tools are classified as development dependencies, so an absent runtime import of Black or pytest is not falsely reported as an unused runtime package. Dynamically loaded dependencies need explicit documented validation.

CI builds a wheel and sdist, rebuilds a second wheel from the sdist, then installs each into a separate clean environment with runtime dependencies only. pip check, source-versus-installed module inventories, all module imports, distribution version and console entry-point checks run outside the checkout with isolated Python. CLI help/version are exercised there too. This catches common packaging and dependency failures; it does not replace behavioral unit, integration, native-kernel or optional-backend qualification.

tools/cli_smoke.py VERSION CONSOLE FIXTURE_DIRECTORY --backend reference|cpu|cuda|auto also checks an installed command from temporary working directories using an explicitly configured external fixture. It verifies capture receipts, changed and missing-data exits, qualified why/save/repeat, all six JSON/CSV exports, precise selected IDs, checksum companions, report units and clean result/diagnostic streams. CI runs it on the wheel and rebuilt source-distribution wheel, before and after installing the CPU extra. Unit fault probes verify that plausible distribution, metadata, dispatch, identity and checksum regressions fail this gate.

Each isolated distribution also installs the CUDA extra and runs tools/package_smoke.py ... --cuda to catch binary import, compiler-profile and required-API breaks. This check requires no GPU. Real-device borrowing and kernel qualification use the separately recorded hardware target.

Releases and documentation

The delivery pipeline validates the source, both package builds and the static documentation before creating a release. An approved SHA256 manifest binds the wheel, source distribution and complete documentation archive to the source snapshot. The publishing workflow verifies that manifest and the checked-out source before uploading the prepared packages; it does not rebuild them.

GitHub Releases carries the wheel, source archive and checksum manifest. PyPI publishing uses the repository’s trusted publisher. Documentation is deployed to the hosted site using keyless authentication. Development versions remain marked as prereleases.

The badge generator uses the successful unit-test JUnit report, Coverage.py JSON and XML reports, and completed quality-gate results. It renders SVGs locally with genbadge; their test counts and coverage are measured values. The same site includes a validation summary.

To generate badges from a completed report directory:

poetry run python tools/badges.py --reports REPORT_DIRECTORY --output OUTPUT_DIRECTORY --version 0.1.0.dev0

The report directory must contain junit-unit.xml, coverage-unit.json, coverage-unit.xml and quality-gates.json. Missing or unsuccessful checks stop generation rather than producing a passing badge.