Can we have sbom-files in [project] table?

Packaging
1

So based on PEP 770, I’d like to have SBOMs in my project. Currently, I use hatchling with:

[tool.hatch.build.targets.wheel]
...
sbom-files = [".../sbom.json"]

And I wonder if we can standardize having this in the [project] table. As we have license-files. Thanks

cc @sethmlarson @ofek

3 Likes
2

We can have this when PEP 808 is accepted. See the explanation about SBOMs under PEP 808 – Including static values in dynamic metadata | peps.python.org for why.

3

I am interested in static metadata here.

4

That doesn’t really change what I said. An earlier version of PEP 770 actually included what you asked about. If you read the PEP 770 discussion thread, there’s a lot of discussion about many SBOM use cases being inherently dynamic, or a mix between static and dynamic. So introducing a standardized static-only [project]-level key that will therefore not be usable by most of the packages that need SBOMs most isn’t the best idea (or at least, that was the outcome of that whole discussion). PEP 808 addresses that key concern.

2 Likes
5

To put that another way, a PEP to add standardised a SBOM field in the [project] table is reasonable, but it needs to wait until PEP 808 is accepted in order to have a good chance of success.

2 Likes
6

Please forgive me if I’m misunderstanding, but I think PEP 770’s definition of “PEP 770 SBOM files are files in .dist-info/sboms instead of using PEP 639’s approach with fields means we don’t need dynamic metadata anymore? No metadata is set when using PEP 770 SBOMs. In the original design of PEP 770 we were running into the dynamic metadata issue for SBOMs, but I’m not sure the final version would be blocked on this issue.

That being said, I’m all for standardizing a [project] field for sbom-files. +1 from me.

1 Like
7

Right. To clarify, I am looking for a standardized way to tell the build backend which files to put in that location when it creates it.

8

I know! I’m saying all of this because I don’t think you’d have to wait for PEP 808 for a PEP about adding sbom-files to [project] because PEP 770 doesn’t use packaging metadata the same way PEP 639 does (cc @pf_moore and @rgommers to confirm if my thinking is correct here?)

9

It’s actually a good question, and a little more subtle than it seems on the face of it. From the spec for the [project] table,

The [project] table specifies the project’s core metadata.

The problem here is that SBOMs are not core metadata, they are additional files that are held elsewhere in the distribution metadata (and importantly, are not defined in the “core metadata” spec).

I don’t think that should be an issue in itself, we can always change the pyproject.toml spec wording if it’s sensible to do so, but the following paragraph on dynamic metadata then gets in the way:

There are two kinds of metadata: static and dynamic. Static metadata is specified in the pyproject.toml file directly and cannot be specified or changed by a tool (this includes data referred to by the metadata, e.g. the contents of files referenced by the metadata). Dynamic metadata is listed via the dynamic key (defined later in this specification) and represents metadata that a tool will later provide.

If we accept that SBOMs can go in the [project] section, then the whole business about dynamic and static values applies, and that’s where we get a problem because I’d argue that build backends adding SBOMs on top of the ones specified in [project] counts as a tool changing the data.

We could argue that SBOM data should be excluded from the whole static/dynamic thing, because it’s (sort of) not core metadata, but that would be quite messy to express clearly. IMO it’s much easier to wait for PEP 808, and then add a SBOM field. The spec would still need a bit of careful wording to cover the fact that [project] is no longer only about core metadata, but at least there wouldn’t need to be exclusions around dynamic.

So from a practical POV, waiting for PEP 808 is likely to be easier[1]. And it makes writing the SBOM PEP simpler as well, because the rules about dynamic will not need to be discussed.

  1. Not just for the PEP authors, but for me too - I don’t have to ensure that the rules around what is static are the same between the two PEPs… ↩︎

5 Likes
10

As the author of support for PEP 770 in hatchling, you have my support for standardizing this in the project table. So a +1 from me. I would default to Paul and Ralf on what they are saying about waiting for PEP 808 in order to ensure a chance at success.

2 Likes
11

I agree with @pfmoore’s assessment, it seems to explain all the relevant aspects well, so I don’t have much to add. PEP 808 discussion seems down to the last little details, so hopefully this won’t be much of a delay. Helping move that along would be the best course of action if anyone is in a hurry with adding sbom-files to [project].

1 Like