feat: Add PEP 770 SBOM files support (wheel.sbom-files setting)

[andife]

Description

Implements PEP 770 – Software Bill of Materials (SBOM) support for scikit-build-core wheels. Users can include SBOM files in their wheel distributions via the wheel.sbom-files configuration option. Files are copied into the *.dist-info/sboms/ directory, format-agnostic (SPDX and CycloneDX both work).

Changes

1. Settings model — sbom_files: Optional[List[str]] = None in WheelSettings, with override inheritance support (none/append/prepend)
2. JSON schema — wheel.sbom-files array property + override inheritance wiring
3. Wheel building — SBOM files validated and copied into *.dist-info/sboms/; raises FileNotFoundError for missing files
4. Documentation — docs/reference/configs.md entry, mirrors wheel.license-files style
5. Tests — in tests/test_pyproject_pep770.py, parametrized over SPDX and CycloneDX

Key design decision: copy timing

SBOM files are copied after builder.install(), not at settings-load time. This means a CMake target can generate the SBOM file into the build directory and wheel.sbom-files can point to that path — the file will exist by the time the check runs.

This was motivated by looking at how onnx/onnx implements PEP 770: they generate a CycloneDX SBOM dynamically from FetchContent_Declare blocks in CMakeLists.txt during the build. With a pre-CMake placement that workflow would have failed with FileNotFoundError.

Discussion points

1. The evidence.occurrences gap

onnx annotates each SBOM component with evidence.occurrences — the paths of the compiled .so/.pyd binaries that contain the statically-linked dependency. This annotation only makes sense after CMake installs the binaries into wheel_dirs. The current implementation has no hook between builder.install() and WheelWriter where user code could inspect wheel_dirs and mutate the SBOM.

For onnx's specific case this is workable (the binary name is known at configure time, so CMake can write a fully-annotated SBOM directly). But the general pattern — inspect what actually landed in the wheel, then annotate — would require a post-install hook. Should scikit-build-core expose one?

2. SBOM generation as a first-class concern

Both hatchling (initialize() hook) and the onnx approach (custom bdist_wheel subclass) treat SBOM generation as part of the build, not just inclusion of pre-existing files. A future wheel.post-install hook receiving wheel_dirs would let projects generate or annotate SBOMs with full knowledge of the wheel contents, which is what PEP 770's evidence fields are designed for.

3. [project] table standardisation

There is ongoing discussion about whether sbom-files should live in the [project] table (like license-files in PEP 639) rather than in tool-specific sections. This is deferred pending PEP 808 (dynamic metadata). The current [tool.scikit-build.wheel] placement is consistent with how hatchling handles it today.

[cbourjau]

Is there really any change needed here to support PEP 770? Can't we just use the existing SKBUILD_METADATA_DIR as documented here

[LecrisUT]

Is there really any change needed here to support PEP 770? Can't we just use the existing SKBUILD_METADATA_DIR as documented here

Indeed that. Afaik there is no standard on CMake side to define and install sboms, if it were, we could automate it in some form. The current form is only to support static-file sboms, which might be fine for some cases, but it does not cover what the actual CMake state was, e.g. did libfoo get linked statically or dynamically, which libraries are used in the final library vs for build only.

Coming from the other side, I do not see a specific format that the sboms should have. That we then enforce. And what are the default values to provide? Doesn't this need to be present for sdist as well, and it is quite common for these two to differ.