PEP 770: Improving measurability of Python packages with Software Bill-of-Materials

[brettcannon]

@sethmlarson

I’d be happy with the [additional-files] approach! I’m assuming we’d adopt the same definition of a list of file globs to define the files in keys in this table?

That’s your call as PEP author, but probably? I do know, though, that PEP 639, Round 3: Improving license clarity with better package metadata - #174 by abravalheri is asking for a reference implementation for verifying the glob pattern meets the spec which we should do if we are going to have more standards rely on it.

@pf_moore

How specific do you want to be in this PEP? I can see two obvious approaches:

1. [additional-files] is simply a new top-level key, and future standards can use it however they like (or ignore it and invent their own mechanism).
2. [additional-files] is reserved for use by standards to define data that will end up in the .dist-info directory, specifically. This avoids any need to start worrying about whether it’s going to work for specifying files that will become part of the installed package itself (which is a much more complex question).

Good question. I assumed the keys would also need to be standardized, so that’s a bit of a guard rail so people don’t toss in random files into random places. Is there any reason to not start with the assumption that [additional-files] will only pertain to .dist-info but can be changed later if we find it’s too strict? Or do we even need to define this upfront and we all just have shared expectations for the purpose of the table so we know what we are bringing into the pyrproject.toml spec? Otherwise we can just avoid being general and just have an [sbom] table if people are too worried about planning for the future that might not be.