# 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](https://pipewhy-68315.web.app/) 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](https://pipewhy-68315.web.app/quality/).

To generate badges from a completed report directory:

```console
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.
