From 502496bb37912d55b844c7c00cdb2a5f70a7867f Mon Sep 17 00:00:00 2001 From: Seth Michael Larson Date: Thu, 27 Feb 2025 13:07:40 -0600 Subject: [PATCH] Address more review comments --- peps/pep-0770.rst | 32 +++++++++++++++++++------------- 1 file changed, 19 insertions(+), 13 deletions(-) diff --git a/peps/pep-0770.rst b/peps/pep-0770.rst index 1fd6c37f9b8..0f48080d5e0 100644 --- a/peps/pep-0770.rst +++ b/peps/pep-0770.rst @@ -29,9 +29,6 @@ frameworks. This PEP proposes using SBOM documents included in Python packages as a means to improve automated software measurability for Python packages. -The changes will update the -`Core Metadata specification `__ to version 2.5. - Motivation ========== @@ -155,13 +152,19 @@ begin emitting the new metadata version, again wait for releases, and only then can projects begin using the new features. Even with this careful approach it's not guaranteed that tools won't break on new metadata versions and fields. -To avoid this delay, this PEP proposes a new mechanism ``[additional-files]`` -to safely add data to a Python package through a registry of reserved names that +To avoid this delay, simplify overall how to include SBOMs, and to give +flexibility to build backends and tools, this PEP proposes a new top-level table +in ``pyproject.toml``, ``[additional-files]``, to safely add data to a Python +package through a registry of reserved names that avoids the need for new metadata fields and versions. This mechanism allows build backends and tools to begin using the features described in this PEP immediately after acceptance without the head-of-line blocking on other projects adopting the PEP. +A new top-level table was chosen over using the ``[project]`` table because, +as described in :pep:`621`, the ``[project]`` table is used for storing core +metadata and this mechanism doesn't use core metadata. + What are the differences between PEP 770 and PEP 725? ----------------------------------------------------- @@ -172,8 +175,8 @@ software within Python packaging metadata. This section aims to show how these two PEPs are tracking different information and serving different use-cases: * PEP 725 describes **abstract dependencies**, such as requiring "a C compiler" - as a build-time dependency (``virtual:compiler/c``) or an "OpenSSL-like - library" (``pkg:generic/openssl``). PEP 770 describes + as a build-time dependency (``virtual:compiler/c``) or needing to link "the + OpenSSL library" at build time (``pkg:generic/openssl``). PEP 770 describes **concrete dependencies**, more akin to dependencies in a "lock file", such as an exact name, version, architecture, and hash of a software library distributed through AlmaLinux distribution @@ -241,14 +244,17 @@ the ``.dist-info`` directory for the :term:`distribution archive` and :term:`installed project` s project types. Future additions to this registry will be made through the PEP process. The initial values in this registry are: -================= ========== -Subdirectory name PEP -================= ========== +================= ============== +Subdirectory name PEP / Standard +================= ============== ``licenses`` :pep:`639` -``license_files`` N/A (See :ref:`770-backwards-compat`) -``LICENSES`` N/A (See :ref:`770-backwards-compat`) +``license_files`` :pep:`639` (draft-only) +``LICENSES`` `REUSE licensing framework `__ ``sboms`` :pep:`770` -================= ========== +================= ============== + +See :ref:`770-backwards-compat` for a complete methodology for +creating this initial set of values to avoid backwards incompatibility issues. .. _770-spec-project-source-metadata: