Skip to content

Commit 8452e54

Browse files
authored
PEP 770: Fix a handful of review comments (#4366)
1 parent 53979d0 commit 8452e54

File tree

1 file changed

+7
-21
lines changed

1 file changed

+7
-21
lines changed

peps/pep-0770.rst

Lines changed: 7 additions & 21 deletions
Original file line numberDiff line numberDiff line change
@@ -105,8 +105,7 @@ including the need to keep up-to-date as SBOM standards continue to evolve
105105
to suit new needs in that space.
106106

107107
Instead, this proposal delegates SBOM-specific metadata to SBOM documents that
108-
are included in Python packages and adds a new Core Metadata field for
109-
discoverability of included SBOM documents.
108+
are included in Python packages into a named directory under dist-info.
110109

111110
This standard also doesn't aim to replace Core Metadata with SBOMs,
112111
instead focusing on the SBOM information being supplemental to Core Metadata.
@@ -463,29 +462,16 @@ Syft and Grype SBOM and vulnerability scanners.
463462
Rejected Ideas
464463
==============
465464

466-
Why not require a single SBOM standard?
467-
---------------------------------------
468-
469-
Most discussion and development around SBOMs today focuses on two SBOM
470-
standards: `CycloneDX <cyclonedxspec_>`_ and `SPDX <spdxspec_>`_. There is no clear
471-
"winner" between these two standards, both standards are frequently used by
472-
projects and software ecosystems.
473-
474-
Because both standards are frequently used, tools for consuming and processing
475-
SBOM documents commonly need to support both standards. This means that this PEP
476-
is not constrained to select a single SBOM standard by its consumers and thus
477-
can allow tools creating SBOM documents for inclusion in Python packages to
478-
choose which SBOM standard works best for their use-case.
479-
480-
Rejected Ideas
481-
==============
482-
483-
Selecting a single SBOM standard
465+
Requiring a single SBOM standard
484466
--------------------------------
485467

486468
There is no universally accepted SBOM standard and this area is still
487469
rapidly evolving (for example, SPDX released a new major version of their
488-
standard in April 2024). To avoid locking the Python ecosystem into a specific
470+
standard in April 2024). Most discussion and development around SBOMs today
471+
focuses on two SBOM standards: `CycloneDX <cyclonedxspec_>`_ and
472+
`SPDX <spdxspec_>`_.
473+
474+
To avoid locking the Python ecosystem into a specific
489475
standard ahead of when a clear winner emerges this PEP treats SBOM documents
490476
as opaque and only makes recommendations to promote compatibility with
491477
downstream consumers of SBOM document data.

0 commit comments

Comments
 (0)