Redo the interface for SBOM generation

[dmikusa]

Describe the Enhancement

I would like to see the SBOM generation reworked behind a new interface or abstraction. We had some limits imposed when this functionality was added because we didn't want to break compatibility in v1. That is not a concern with v2, so we should rethink the SBOM interface and abstractions in the library.

In particular, I would like to be able to easily swap in/out different SBOM generators w/out causing changes to core code.

Motivation

SBOM is an area where things are still changing rapidly. We need to be flexible. We also need to support multiple tools, because Syft is not the only tool folks want to use.

[loewenstein]

Could we actually deprecate the old SBOM logic and compatibly introduce an alternative? That would decouple this from bumping the major version of libpak - at least until we want to eventually remove the deprecated API.

[dmikusa]

Possibly, but the thought with this issue is that we won't be able to introduce a new API that is acceptable without breaking the API in some way. The previous attempt had limits to which we could go without breaking things, so I'm hoping that we can break things so that we can arrive at an API that is better suited for the task.

[loewenstein-sap]

If nobody is actively working on this, may I suggest to release v2 and move this to the next major?

[dmikusa]

As much as the present interface bothers me, it's very low priority for me so I've definitely been thinking about pushing this back to the next major release. It's just a big thing, cause that will hopefully not be for multiple years. 🤔