# PEP 770: Improving measurability of Python packages with Software Bill-of-Materials
**URL:** https://discuss.python.org/t/pep-770-improving-measurability-of-python-packages-with-software-bill-of-materials/76308
**Category:** Standards
**Created:** [January 6, 2025, 8:59pm UTC](https://discuss.python.org/t/pep-770-improving-measurability-of-python-packages-with-software-bill-of-materials/76308 "2025-01-06T20:59:21Z")
**Posts on this page:** 20
**Page:** 5
### Author:  [@ofek](https://discuss.python.org/u/ofek)
#### Post date: [February 26, 2025, 11:53pm UTC](https://discuss.python.org/t/pep-770-improving-measurability-of-python-packages-with-software-bill-of-materials/76308/81 "2025-02-26T23:53:00Z")
A `[distribution.metadata-files]` table sounds great! I was trying to maintain the relationship between TOML fields and metadata in an artifact, and a top level `[distribution]` table is indeed much better.
---
### Author:  [@brettcannon](https://discuss.python.org/u/brettcannon)
#### Post date: [February 27, 2025, 1:02am UTC](https://discuss.python.org/t/pep-770-improving-measurability-of-python-packages-with-software-bill-of-materials/76308/82 "2025-02-27T01:02:18Z")
> [@ofek](#):
>
> The wheel builder in Hatchling has an `extra-metadata` [option](https://hatch.pypa.io/latest/plugins/builder/wheel/#options) that allows one to ship arbitrary files under `.dist-info/extra_metadata`. Can we please standardize something like that for folks to use? It would correspond to the `extra` key under the `[project.metadata-files]` table.
Any reason to not have a `tool` directory whose own subdirectories are scoped to the build tool, e.g. `.dist-info/tool/hatchling`? Then you can put whatever you want in there?
> [@ofek](#):
>
> A `[distribution.metadata-files]` table sounds great!
My concern with that name is the files have nothing to do with core metadata. Granted, most users will probably not make that connection, but it’s where my brain went. If we wanted to stick with the `.dist-info` connection then `distribution.info-files` also makes sense, as well as `distribution.info` or even `distribution.info.files` if you really want to scope to file-related keys because “[Namespaces are one honking great idea](https://peps.python.org/pep-0020/)”.
---
### Author:  [@ofek](https://discuss.python.org/u/ofek)
#### Post date: [February 27, 2025, 2:32am UTC](https://discuss.python.org/t/pep-770-improving-measurability-of-python-packages-with-software-bill-of-materials/76308/83 "2025-02-27T02:32:30Z")
> [@brettcannon](#):
>
> Any reason to not have a `tool` directory whose own subdirectories are scoped to the build tool, e.g. `.dist-info/tool/hatchling`? Then you can put whatever you want in there?
The reason would be to allow users distributing whatever auxiliary package metadata they want using any backend.
> [@brettcannon](#):
>
> My concern with that name is the files have nothing to do with core metadata. Granted, most users will probably not make that connection, but it’s where my brain went.
I think the latter assessment is correct and is the more important consideration. Everything under the `.dist-info` directory is, necessarily and technically, metadata.
edit: I also think that plays nicely with “core metadata” because if you remove “core” and ask what that means, in my view the answer would be everything in that directory.
edit 2: That is actually stated explicitly by the [wheel spec](https://packaging.python.org/en/latest/specifications/binary-distribution-format/#file-contents):
> 1. `{distribution}-{version}.dist-info/` contains metadata.
---
### Author:  [@rgommers](https://discuss.python.org/u/rgommers)
#### Post date: [February 27, 2025, 12:05pm UTC](https://discuss.python.org/t/pep-770-improving-measurability-of-python-packages-with-software-bill-of-materials/76308/84 "2025-02-27T12:05:06Z")
> [@ofek](#):
>
> The reason would be to allow users distributing whatever auxiliary package metadata they want using any backend.
I agree, tool names do not belong in directory names like that. It should be possible to move backends without changing installed file locations. Something like `extra` seems fine.
> [@ofek](#):
>
> Everything under the `.dist-info` directory is, necessarily and technically, metadata.
It’s currently the case and probably a good convention to keep, but it’s not necessary for any technical reason.
As an example of non-metadata that could be put there, one proposal I’ve seen for addressing the problem of where to install header files in a way that they become discoverable (xref [problem description](https://pypackaging-native.github.io/other_issues/#no-good-way-to-install-headers-or-non-python-libraries)) is to use `.dist-info/include`, so build tools can be taught to look for them in a consistent place. There are probably better solutions for the header problem specifically, but not all other files that need a place to go inside a Python environment and outside the import tree of the package are metadata.
So to keep the options open, best not to use “metadata” as part of the directory name. It’s either superfluous (if everything is metadata by convention anyway) or limiting. I kinda liked `[additional-files]`; something like `[distribution.info]`, `[distribution.info-files]` or `[dist-info.files]` all sounds reasonable as well.
---
### Author:  [@ofek](https://discuss.python.org/u/ofek)
#### Post date: [February 27, 2025, 1:43pm UTC](https://discuss.python.org/t/pep-770-improving-measurability-of-python-packages-with-software-bill-of-materials/76308/85 "2025-02-27T13:43:09Z")
> [@rgommers](#):
>
> > [@ofek](#):
> >
> > Everything under the `.dist-info` directory is, necessarily and technically, metadata.
>
> It’s currently the case and probably a good convention to keep […] As an example of non-metadata that could be put there, one proposal I’ve seen for addressing the problem of where to install header files in a way that they become discoverable […] is to use `.dist-info/include`
As I mentioned above, this is not a convention but part of the [wheel spec](https://packaging.python.org/en/latest/specifications/binary-distribution-format/#file-contents):
> `{distribution}-{version}.dist-info/` contains metadata.
Therefore I think it’s unwise to, for example, ship header files there. There is already a naming convention used by the spec to ship such non-importable files which is `{distribution}-{version}.{key}` e.g.:
> `{distribution}-{version}.data/` contains one subdirectory for each non-empty install scheme key not already covered, where the subdirectory name is an index into a dictionary of install paths (e.g. `data`, `scripts`, `headers`, `purelib`, `platlib`).
So one could easily add a new known `{distribution}-{version}.include` directory to the spec.
---
### Author:  [@sethmlarson](https://discuss.python.org/u/sethmlarson)
#### Post date: [February 27, 2025, 2:37pm UTC](https://discuss.python.org/t/pep-770-improving-measurability-of-python-packages-with-software-bill-of-materials/76308/86 "2025-02-27T14:37:12Z")
> [@rgommers](#):
>
> I kinda liked `[additional-files]`;
I also liked the name `additional-files`, it felt user-focused and that seems important for `pyproject.toml`.
> [@AA-Turner](#):
>
> it seems that this is explicitly meant for files to be included in a distribution package.
Most of the naming conversation has been `.dist-info`-focused so I wanted to note that there’s utility beyond the files being in `.dist-info`: this information is also useful to tools that are inspecting source distributions for files of a certain category. The reason files are put into `.dist-info/{directory}` is so that tools beyond `pyproject.toml` can add more files as needed without having to change the core metadata of a package.
Throwing a few names out there that I think are also fine?
- `metadata-files`
- `additional-metadata`
My only thought on `extra-*` is that the term is already used for something else in Python packaging, so I’d like to avoid adding more uses. My aversion to `dist-*` or `distribution-*` is that users don’t think about that word when they think about a Python package, IMO?
---
### Author:  [@steve.dower](https://discuss.python.org/u/steve.dower)
#### Post date: [February 27, 2025, 4:00pm UTC](https://discuss.python.org/t/pep-770-improving-measurability-of-python-packages-with-software-bill-of-materials/76308/87 "2025-02-27T16:00:52Z")
> [@ofek](#):
>
> > `{distribution}-{version}.data/` contains one subdirectory for each non-empty install scheme key not already covered, where the subdirectory name is an index into a dictionary of install paths (e.g. `data`, `scripts`, `headers`, `purelib`, `platlib`).
>
> So one could easily add a new known `{distribution}-{version}.include` directory to the spec.
The spec already says to use `{distribution}-{version}.data/headers/` for headers, no? In the bit that you quoted?
Otherwise, I’d standardise on an entrypoint rather than a directory name for things that are going to be discovered at runtime.
* * *
Which I guess also raises the question, why not `{distribution}-{version}.data/sboms/`? Is there a concern about all SBOMs for an environment being installed to the same location?
---
### Author:  [@ofek](https://discuss.python.org/u/ofek)
#### Post date: [February 27, 2025, 4:14pm UTC](https://discuss.python.org/t/pep-770-improving-measurability-of-python-packages-with-software-bill-of-materials/76308/88 "2025-02-27T16:14:28Z")
> [@steve.dower](#):
>
> The spec already says to use `{distribution}-{version}.data/headers/` for headers, no? In the bit that you quoted?
Oh wow, true! @rgommers It appears like what you mentioned has been supported for a long time.
---
### Author:  [@sethmlarson](https://discuss.python.org/u/sethmlarson)
#### Post date: [February 27, 2025, 5:44pm UTC](https://discuss.python.org/t/pep-770-improving-measurability-of-python-packages-with-software-bill-of-materials/76308/89 "2025-02-27T17:44:50Z")
> [@steve.dower](#):
>
> Which I guess also raises the question, why not `{distribution}-{version}.data/sboms/`? Is there a concern about all SBOMs for an environment being installed to the same location?
It sounds like the difference between `.dist-info/{dir}` and `.data/{dir}` is that the data directory needs to merge all the contents into one directory? If so, I’m concerned about merging all files into one directory if we’re not allowed to perform an automatic transformation on install time, I suspect many projects would have conflicting SBOM names (`bom.cdx.json`). I’m assuming this is the same reason `.data` wasn’t chosen for license files which are all named `LICENSE` @brettcannon and @ksurma?
---
### Author:  [@steve.dower](https://discuss.python.org/u/steve.dower)
#### Post date: [February 27, 2025, 5:48pm UTC](https://discuss.python.org/t/pep-770-improving-measurability-of-python-packages-with-software-bill-of-materials/76308/90 "2025-02-27T17:48:11Z")
The same thing applies to headers. It relies on users including their files in a subdirectory in the data directory, which doesn’t seem any more burdensome than any of the other requirements (but as we know, I’m very much “anything goes” about this stuff, so if you wanted to require that SBOMs go in `.data/sboms/{package_name}/` then I’d ~~ignore it~~ not complain 😉 )
My guess on licenses is that license data was previously in `.dist-info`, and so it continues to be in `.dist-info`, just moved from `METADATA` into a separate file.
---
### Author:  [@pf\_moore](https://discuss.python.org/u/pf_moore)
#### Post date: [February 27, 2025, 6:06pm UTC](https://discuss.python.org/t/pep-770-improving-measurability-of-python-packages-with-software-bill-of-materials/76308/91 "2025-02-27T18:06:55Z")
You should read [the wheel spec](https://packaging.python.org/en/latest/specifications/binary-distribution-format/#file-contents) for details, but essentially the directory `{distribution}-{version}.data/` _in a wheel_ contains a set of subdirectories - `{distribution}-{version}.data/include`, for example. The names of these subdirectories are intended to correspond to install scheme keys (see [the `sysconfig` documentation](https://docs.python.org/3.13/library/sysconfig.html#installation-paths) for details, and when installing the wheel, the contents of the directories are copied into the corresponding locations.
I don’t think this is suitable for SBOM data for a few reasons:
1. There’s no `sbom` sysconfig path. One could be added for Python 3.14+, but it would be unsupported on older versions of Python, delaying SBOM support until Python 3.14+ is the default version people use.
2. The `.data/{dir}` directories have no corresponding location in the _installed_ package. The target location is a shared directory, and as you say this could result in name clashes when different projects use the same SBOM file name.
Conversely, `.dist-info` is a directory that’s present in _both_ the wheel and the installed distribution, and it is project-specific, so there’s no risk of clashes. It’s reserved for “metadata” - the relevant point in the wheel spec says
> `{distribution}-{version}.dist-info/` contains metadata.
… but I think it’s reasonable to consider SBOM files as “metadata” in this sense.
The point about include files is a bit of a distraction - I assume the reason @rgommers is suggesting that include files could go in `.dist-info` is because the situation around the sysconfig `include` location is a bit of a mess\[1\], so `.data/include` isn’t as useful as it could be.
* * *
1. I don’t recall the details and it’s off-topic for this discussion, but I think there’s a bunch of special casing and exceptions that is done for “historical reasons”…
---
### Author:  [@steve.dower](https://discuss.python.org/u/steve.dower)
#### Post date: [February 27, 2025, 8:38pm UTC](https://discuss.python.org/t/pep-770-improving-measurability-of-python-packages-with-software-bill-of-materials/76308/92 "2025-02-27T20:38:48Z")
> [@pf\_moore](#):
>
> There’s no `sbom` sysconfig path. One could be added for Python 3.14+, but it would be unsupported on older versions of Python, delaying SBOM support until Python 3.14+ is the default version people use.
I thought we agreed to start defining them separately, and just use `sysconfig` as the initial set (until we needed to add more)?
Or did I imagine that? I don’t see any updates in the current spec, but I’m sure I remember discussing them.
---
### Author:  [@pf\_moore](https://discuss.python.org/u/pf_moore)
#### Post date: [February 27, 2025, 8:46pm UTC](https://discuss.python.org/t/pep-770-improving-measurability-of-python-packages-with-software-bill-of-materials/76308/93 "2025-02-27T20:46:19Z")
> [@steve.dower](#):
>
> Or did I imagine that? I don’t see any updates in the current spec, but I’m sure I remember discussing them.
I’m not aware of a PEP for that (and I’m pretty sure it would need a PEP). I think we’ve briefly discussed improving things in that area (maybe in the “wheel next generation” thread) but nothing concrete.
---
### Author:  [@sethmlarson](https://discuss.python.org/u/sethmlarson)
#### Post date: [February 27, 2025, 10:05pm UTC](https://discuss.python.org/t/pep-770-improving-measurability-of-python-packages-with-software-bill-of-materials/76308/94 "2025-02-27T22:05:58Z")
Thanks for clarifying that all, I’ve been slowly incorporating the pieces we’re discussing into the [open pull request](https://github.com/python/peps/pull/4283) for adding the new top-level table. I think the only two questions I have are:
- Is the question of using `.dist-info` instead of `.data` settled? If so I can add a section summarizing the above as rationale.
- What are we naming our shed? 🙂
---
### Author:  [@brettcannon](https://discuss.python.org/u/brettcannon)
#### Post date: [February 27, 2025, 10:35pm UTC](https://discuss.python.org/t/pep-770-improving-measurability-of-python-packages-with-software-bill-of-materials/76308/95 "2025-02-27T22:35:28Z")
> [@sethmlarson](#):
>
> Is the question of using `.dist-info` instead of `.data` settled?
I think so.
> [@sethmlarson](#):
>
> What are we naming our shed?
As PEP author it’s your shed to paint, just list reasons as to why you chose the colour.
---
### Author:  [@rgommers](https://discuss.python.org/u/rgommers)
#### Post date: [February 28, 2025, 11:38am UTC](https://discuss.python.org/t/pep-770-improving-measurability-of-python-packages-with-software-bill-of-materials/76308/96 "2025-02-28T11:38:43Z")
> [@ofek](#):
>
> > [@steve.dower](#):
> >
> > The spec already says to use `{distribution}-{version}.data/headers/` for headers, no? In the bit that you quoted?
>
> Oh wow, true! @rgommers It appears like what you mentioned has been supported for a long time.
No, this is misunderstanding the situation - the `headers` key has existed for a long time but is strongly discouraged, as it may install to global locations like `/usr/local/include`. It’s not suitable for default usage. Very few packages actually use this; one is `pybind11` which has a `pybind11[global]` variant (rarely seen in use in the wild) which lets the user opt in to installing headers this way. Pybind11 [documents](https://pybind11.readthedocs.io/en/stable/installing.html#include-with-pypi) the behavior with a “It’s not recommended if”. The explanation I linked to says as much: _" This is technically possible with wheels, but recommended against because the install process may clobber system files."_.
Anyway, it’s just one example, I did not mean to start a discussion about headers. The point was that there are going to be other needs for installing files that aren’t currently catered for.
This major caveat applies to the `data` dir in general, it’s possible to use it in wheels, but is mostly useful for wheels that aren’t meant for distribution on PyPI. It is not suitable as a default for major projects like Pybind11, NumPy, PyArrow, etc. because of potentially writing to system locations.
> [@pf\_moore](#):
>
> The `.data/{dir}` directories have no corresponding location in the _installed_ package. The target location is a shared directory, and as you say this could result in name clashes when different projects use the same SBOM file name.
Yep, this (and your whole post was spot on). It may apply to other types files than only SBOMs (other example: what about pkg-config or `.cmake` files, they have nowhere to go either, and with a bit of handwaving they could even be considered metadata).
---
### Author:  [@sethmlarson](https://discuss.python.org/u/sethmlarson)
#### Post date: [February 28, 2025, 8:06pm UTC](https://discuss.python.org/t/pep-770-improving-measurability-of-python-packages-with-software-bill-of-materials/76308/97 "2025-02-28T20:06:44Z")
Okay folks, [last update](https://github.com/python/peps/pull/4283/commits/2afcfa04257634d64dc2fc8637960ae1ec2d3b00) before I’m without internet for the weekend. I’ve decided to put forward `[dist-info.files]` as the new top-level table name. I’ve updated all the [pull request](https://github.com/python/peps/pull/4283/commits/2afcfa04257634d64dc2fc8637960ae1ec2d3b00) to reflect this, my justifications below:
- The name `dist-info.files` has good values for searchability and “does what it says on the tin”. This will be useful to conceptually map the table and keys in `pyproject.toml`, the expected behavior of tools, and the registry of reserved `dist-info` subdirectory names into a cohesive story.
- Avoiding the word “metadata” means we’re not painted into a corner about what type of files are used in the future, even if the identified use-cases today are all metadata.
- Avoiding the word “extra” to not overload the existing term for optional dependencies.
- No ambiguity about the “what”, which was the identified problem with using “additional-\*”.
Of all the names I also liked that the table name feels symmetrical for the source distribution lookup case too, for example if a tool is looking for statically defined SBOMs in an sdist they examine `pyproject.toml` for `dist-info.files` and the `sboms` key, this is a similar-looking story to searching in `.dist-info` and the `sboms` directory of a built distribution.
Thanks all for the great ideas and discussion, please let me know what you think or if you have reservations about my justifications/choices.
---
### Author:  [@pf\_moore](https://discuss.python.org/u/pf_moore)
#### Post date: [February 28, 2025, 8:20pm UTC](https://discuss.python.org/t/pep-770-improving-measurability-of-python-packages-with-software-bill-of-materials/76308/98 "2025-02-28T20:20:21Z")
Only one question from me - this leaves open the possibility of `[dist-info.something]` for subkeys _other_ than `files`. I can’t immediately think of anything else that might be needed here. So are we adding an unnecessary level? Conversely, does it matter?
I do like the readability of `dist-info.files.sboms`, so I don’t object to the naming, I’m just curious why you added the extra level. (Or is it simply that you weren’t aware that using a dot _did_ add an extra level?)
---
### Author:  [@sethmlarson](https://discuss.python.org/u/sethmlarson)
#### Post date: [March 3, 2025, 6:46pm UTC](https://discuss.python.org/t/pep-770-improving-measurability-of-python-packages-with-software-bill-of-materials/76308/100 "2025-03-03T18:46:22Z")
> [@pf\_moore](#):
>
> I do like the readability of `dist-info.files.sboms`, so I don’t object to the naming, I’m just curious why you added the extra level. (Or is it simply that you weren’t aware that using a dot _did_ add an extra level?)
I did know that adding a dot added an extra level, this was not wanting to paint “`dist-info`”, a potentially multi-faceted namespace in the future, into a corner, only being used for a single mechanism (plus like you said, `dist-info.files.sboms` seemed just fine)
---
### Author:  [@ofek](https://discuss.python.org/u/ofek)
#### Post date: [March 5, 2025, 1:25pm UTC](https://discuss.python.org/t/pep-770-improving-measurability-of-python-packages-with-software-bill-of-materials/76308/101 "2025-03-05T13:25:08Z")
This is my final attempt to advocate for different naming. I don’t consider it bikeshedding because this is meaningful for users.
* * *
I still think we should go with a top-level `metadata-files`.
This option is user-facing so when you say:
> [@sethmlarson](#):
>
> if a tool is looking for statically defined SBOMs in an sdist they examine `pyproject.toml` for `dist-info.files` and the `sboms` key, this is a similar-looking story to searching in `.dist-info` and the `sboms` directory of a built distribution
To me that doesn’t matter at all for users, exactly because of the reason you mentioned earlier in this thread:
> [@sethmlarson](#):
>
> My aversion to `dist-*` or `distribution-*` is that users don’t think about that word when they think about a Python package
This option is all about the user and the vast majority of users have no idea that wheels ship a directory suffixed by `.dist-info`. Also from a technical standpoint if we ever choose to add more metadata to source distributions, or invent new types of artifacts that require metadata, then we are stuck with that name there as well.
Please reconsider the naming so we can offer the best possible UX.
[Previous page](https://discuss.python.org/t/pep-770-improving-measurability-of-python-packages-with-software-bill-of-materials/76308.md?page=4)
[Next page](https://discuss.python.org/t/pep-770-improving-measurability-of-python-packages-with-software-bill-of-materials/76308.md?page=6)