Survey of Python wheel "repairing" tools

[sethmlarson]

Tools that bundle software into wheels on behalf of users post-build, typically during continuous integration runs. The common tools that I've seen for this are:

• auditwheel (manylinux, musllinux)
• delocate (macOS)
• delvewheel (Windows)
• repairwheel (cross-platform CLI using the other three tools)

The toughest question for all of these tools are whether they can reliably find software identifiers that are relevant. Package URLs should be possible for manylinux, musllinux, and projects using Homebrew on macOS. Where software IDs aren't automatically findable, at least there is a "known-unknown" situation happening so consumers can dig deeper and potentially contribute back the missing information.

[di]

at least there is a "known-unknown" situation happening so consumers can dig deeper and potentially contribute back the missing information.

Is this something SBOMs would explicitly have support for? I.e., "something was introduced but we don't have an identifier for it"

[sethmlarson]

@di Yes SBOM standards today have support for known-unknowns. Calling out known-unknowns is required in some SBOM conformance standards like NTIA minimum elements.

[sethmlarson]

I published some early results from a fork of auditwheel to record the software IDs of shared libraries, it seems to have worked fairly well: https://sethmlarson.dev/early-promising-results-with-sboms-and-python-packages