Use it with any other backend¶

Backends without a plugin interface get the SBOM through python_sbom.backend, a build backend that wraps yours. The table below links a guide with a complete project for each backend python-sbom is tested with; this page covers how the wrapper works for those and any other backend. Make python_sbom.backend the project’s backend, keep yours in the build requirements, and name yours in [tool.python-sbom], as the meson-python project does:

pyproject.toml¶

[build-system]
build-backend = "python_sbom.backend"
requires = [ "meson>=1.6", "meson-python>=0.18", "ninja", "python-sbom>=0.3" ]

[project]
name = "greet"
version = "1.0"
description = "says hello"
license = "MIT"
requires-python = ">=3.11"
classifiers = [
  "Programming Language :: Python :: 3 :: Only",
  "Programming Language :: Python :: 3.11",
  "Programming Language :: Python :: 3.12",
  "Programming Language :: Python :: 3.13",
  "Programming Language :: Python :: 3.14",
  "Programming Language :: Python :: 3.15",
]
dependencies = [ "packaging>=24" ]

[tool.python-sbom]
build-backend = "mesonpy"
supplier = { name = "You", url = [ "https://github.com/you" ] }

build-backend takes what [build-system] build-backend took before: a module, or module:object. Every hook a frontend calls goes to your backend unchanged, --config-settings included, and the optional hooks exist only when your backend defines them, so frontends behave as before. Once your backend has written a wheel, the wrapper writes the SBOM into it; once it has written an sdist, it adds the source revision.

The wrapper runs inside the build’s isolated environment, so the SBOM lists the tools that built the wheel, such as meson-python, meson, ninja and patchelf, with the versions the frontend installed.

Each backend¶

Use the module name from your current [build-system] build-backend:

Backend	`[tool.python-sbom] build-backend`	Guide
meson-python	`mesonpy`	Use it with meson-python
scikit-build-core	`scikit_build_core.build`	Use it with scikit-build-core
maturin	`maturin`	Add an SBOM to a maturin project
flit-core	`flit_core.buildapi`	Use it with flit-core
poetry-core	`poetry.core.masonry.api`	Use it with poetry-core
uv_build	`uv_build`	Use it with uv-build
pdm-backend, setuptools	`pdm.backend`, `setuptools.build_meta`	Use it with pdm-backend, Use it with setuptools: use their plugin, and wrap them only when it cannot act

Pitfall: builds that skip the build interface¶

The wrapper runs only when a frontend builds through the standard build interface: pip, uv, python -m build and cibuildwheel do. Tools that call the backend’s own command line do not: maturin build, which maturin-action runs, and meson called directly. Describe those wheels after the build, as Describe a wheel built outside the build interface shows.

Pitfall: a backend in your own tree¶

The wrapper cannot wrap a backend the project ships in its own tree. Such a backend loads through [build-system] backend-path, and a frontend loads only a backend found on that path, so it refuses python_sbom.backend, which lives in the build environment. Describe those wheels after the build, as Describe a wheel built outside the build interface shows.

Pitfall: tools that rename the wheel afterwards¶

auditwheel repair renames a wheel to its manylinux tag, delocate can change its macOS tag, and both may copy shared libraries into it, so the SBOM the wrapper wrote can name the old file and misses those libraries. Run python-sbom embed on the repaired wheel, as Describe a wheel built outside the build interface shows.