Survey of Python build backends handling non-Python software

[sethmlarson]

These build backends are likely to have a more complicated use-case, such as needing to generate their own SBOMs instead of only forwarding along SBOM documents specified in pyproject.toml.

• Maturin and PyO3
• setuptools
• meson-python
• enscons
• scikit-build-core

[ncoghlan]

Additional "full fledged build systems that can emit Python packages" options:

• https://pypi.org/project/enscons/
• https://pypi.org/project/cmake/ (CMake-for-Python-packages, essentially)
• https://pypi.org/project/scikit-build/

There are also projects like zig and compiletools, as well as Rust, where non-Python dependencies may end up statically linked into the resulting extension modules.

There probably needs to be a way to just inject additional SBOM snippets directly, and leave it up to the project itself to manage keeping them in sync with the actual build process. Defining a common way to do that would mean that each affected build system project didn't need to invent one for itself.

[rgommers]

I'd remove CMake and scikit-build from this list, and add scikit-build-core. scikit-build-core is the modern, standards-compliant build backend that effectively supersedes scikit-build. And both use CMake as the build system (generator); CMake itself is not a build backend and doesn't produce wheels, so doesn't need to know about .dist-info/sboms.

Same for PyO3, that doesn't need to be on this list I'd think. Maturin is the build backend.

And meson-build -> meson-python

[rgommers]

xref mesonbuild/meson-python#763 for the meson-python feature request, and PyO3/maturin#2554 for the maturin feature request.

[sethmlarson]

@rgommers Thanks for the links! I've updated the issue accordingly and will be looking at the meson-python feature request thread, too!