From b593a4d3cd28e9a142ca51797a8b9fcc277915bc Mon Sep 17 00:00:00 2001 From: Karolina Surma Date: Thu, 4 Jul 2024 16:33:17 +0200 Subject: [PATCH 1/6] Remove the requirement of license-files defaults --- peps/pep-0639.rst | 22 ---------------------- peps/pep-0639/appendix-rejected-ideas.rst | 16 ++++++++++++++++ 2 files changed, 16 insertions(+), 22 deletions(-) diff --git a/peps/pep-0639.rst b/peps/pep-0639.rst index eb9e941aa26..71d11e16984 100644 --- a/peps/pep-0639.rst +++ b/peps/pep-0639.rst @@ -574,23 +574,6 @@ If the ``license-files`` key is present, and the ``paths`` or ``globs`` subkey is set to a value of an empty array, then tools MUST NOT include any license files and MUST NOT raise an error. -.. _639-default-patterns: - -If the ``license-files`` key is not present and not explicitly marked as -``dynamic``, tools MUST assume a default value of the following: - -.. code-block:: toml - - license-files.globs = ["LICEN[CS]E*", "COPYING*", "NOTICE*", "AUTHORS*"] - -In this case, tools MAY issue a warning if no license files are matched, -but MUST NOT raise an error. - -If the ``license-files`` key is marked as ``dynamic`` (and not present), -to preserve consistent behavior with current tools and help ensure the packages -they create are legally distributable, build tools SHOULD default to -including at least the license files matching the above patterns, unless the -user has explicitly specified their own. Examples of valid license files declaration: @@ -662,11 +645,6 @@ in the core metadata, and MUST include the specified file as if it were specified in a ``license-file.paths`` field. If the file does not exist at the specified path, tools MUST raise an informative error as previously specified. -However, tools MUST also still assume the -:ref:`specified default value <639-default-patterns>` -for the ``license-files`` key and also include, -in addition to a license file specified under the ``license.file`` subkey, -any license files that match the specified list of patterns. Table values for the ``license`` key MAY be removed from a new version of the specification in a future PEP. diff --git a/peps/pep-0639/appendix-rejected-ideas.rst b/peps/pep-0639/appendix-rejected-ideas.rst index 990456c47b2..c59706b6a46 100644 --- a/peps/pep-0639/appendix-rejected-ideas.rst +++ b/peps/pep-0639/appendix-rejected-ideas.rst @@ -476,6 +476,22 @@ the preferred subkey when it was not, and didn't describe the format of the string entry similarly to the existing ``globs``. +Use a default value for ``license-files`` if not specified +'''''''''''''''''''''''''''''''''''''''''''''''''''''''''' + +A previous draft of the PEP proposed a default value for detecting +license files in case the users have not declared any and not marked the key +as dynamic. +That value was defined as an array of globs: +``["LICEN[CS]E*", "COPYING*", "NOTICE*", "AUTHORS*"]`` + +However, this would create an exception among the existing metadata, +as no other key has got implicit defaults defined. Implicit values in +pyproject.toml keys are delegated to the ``dynamic`` field, +which is specified as being calculated. Also, the values were chosen +arbitrarily, without a strong justification why they should pose a standard. + + Must be marked dynamic to use defaults '''''''''''''''''''''''''''''''''''''' From 926952c6383d02c5977f328ff1a37e0bd6b1a22d Mon Sep 17 00:00:00 2001 From: Karolina Surma Date: Thu, 4 Jul 2024 16:47:14 +0200 Subject: [PATCH 2/6] Cover all rejected subkeysideas in one paragraph --- peps/pep-0639/appendix-rejected-ideas.rst | 106 +++------------------- 1 file changed, 15 insertions(+), 91 deletions(-) diff --git a/peps/pep-0639/appendix-rejected-ideas.rst b/peps/pep-0639/appendix-rejected-ideas.rst index c59706b6a46..9f614e40d69 100644 --- a/peps/pep-0639/appendix-rejected-ideas.rst +++ b/peps/pep-0639/appendix-rejected-ideas.rst @@ -149,66 +149,23 @@ Alternative possibilities related to the ``license`` key in the ``pyproject.toml`` project source metadata. -Add ``expression`` and ``files`` subkeys to table -''''''''''''''''''''''''''''''''''''''''''''''''' +Add new subkeys to table +'''''''''''''''''''''''' -A previous draft of PEP 639 added ``expression`` and ``files`` subkeys -to the existing ``license`` table in the project source metadata, to parallel -the existing ``file`` and ``text`` subkeys. While this seemed the -most obvious approach at first glance, it had serious drawbacks -relative to that ultimately taken here. - -This means two very different types of metadata are being -specified under the same top-level key that require very different handling, -and unlike the previous arrangement, the subkeys were not mutually -exclusive and could both be specified at once, with some subkeys potentially -being dynamic and others static, and mapping to different Core Metadata fields. - -There are further downsides to this as well. Both users and tools would need to -keep track of which fields are mutually exclusive with which of the others, -greatly increasing complexity, and the probability -of errors. Having so many different fields under the -same key leads to a much more complex mapping between -``[project]`` keys and Core Metadata fields, not in keeping with :pep:`621`. -This causes the ``[project]`` table naming and structure to diverge further -from both the Core Metadata and native formats of the various popular packaging -tools that use it. Finally, this results in the spec being significantly more -complex to understand and implement than the alternatives. - -The approach PEP 639 now takes, using the reserved top-level string value -of the ``license`` key, adding a new ``license-files`` key -and deprecating the ``license`` table subkeys (``text`` and ``file``), -avoids most of the issues identified above, -and results in a much clearer and cleaner design overall. -It allows ``license`` and ``license-files`` to be tagged -``dynamic`` independently, separates two independent types of metadata -(syntactically and semantically), restores a closer to 1:1 mapping of -``[project]`` table keys to Core Metadata fields, -and reduces nesting by a level for both. -Other than adding one extra key to the file, there was no significant -apparent downside to this latter approach, so it was adopted for PEP 639. - - -Add an ``expression`` subkey instead of a string value -'''''''''''''''''''''''''''''''''''''''''''''''''''''' +There were proposals to add various subkeys to the table. +Combining different types of metadata which require different handling, +adding new guidance regarding the subkeys mutual exclusivity and +the possibility to define some of them as dynamic would make the +transition harder and create more confusion rather than clarity for the users. +This approach has been rejected in favour of more flat ``pyproject.toml`` +design, clear mapping between ``pyproject.toml`` keys and Core Metadata fields, +and increased readability of the separate keys. + +Rejected proposals: -Adding just an ``expression`` subkey to the ``license`` table, -instead of using the top-level string value, -would be more explicit for readers and writers, -in line with PEP 639's goals. -However, it still has the downsides listed above -that are not specific to the inclusion of the ``files`` key. - -Relative to a flat string value, -it adds complexity and an extra level of nesting, -and requires users and tools to remember and handle -the mutual exclusivity of the subkeys -and remember which are deprecated, -instead of cleanly deprecating the table subkeys as a whole. -Furthermore, it is less clearly the "default" choice for modern use, -given users tend to gravitate toward the most obvious option. -Finally, it seems reasonable to follow the suggested guidance in :pep:`621`, -given the top-level string value was specifically reserved for this purpose. +- add ``expression`` and ``files`` subkeys to table +- add an ``expression`` subkey instead of a string value +- add a ``type`` key to treat ``text`` as expression Define a new top-level ``license-expression`` key @@ -267,39 +224,6 @@ Therefore, a top-level string value for ``license`` was adopted for PEP 639, as an earlier working draft had temporarily specified. -Add a ``type`` key to treat ``text`` as expression -'''''''''''''''''''''''''''''''''''''''''''''''''' - -Instead of using the reserved top-level string value -of the ``license`` key in the ``[project]`` table, -one could add a ``type`` subkey to the ``license`` table -to control whether ``text`` (or a string value) -is interpreted as free-text or a license expression. This could make -backward compatibility a bit easier, as older tools could ignore -it and always treat ``text`` as ``license``, while newer tools would -know to treat it as a license expression, if ``type`` was set appropriately. -Indeed, :pep:`621` seems to suggest something of this sort as a possible -way that SPDX license expressions could be implemented. - -However, it has got all the same downsides as in the previous item, -including greater complexity, a more complex mapping between the project -source metadata and Core Metadata and inconsistency between the presentation -in tool config, project source metadata and Core Metadata, -a harder deprecation, further bikeshedding over what to name it, -and inability to mark one but not the other as dynamic, among others. - -In addition, while theoretically a little easier in the short -term, in the long term it would mean users would always have to remember -to specify the correct ``type`` to ensure their license expression is -interpreted correctly, which adds work and potential for error; we could -never safely change the default while being confident that users -understand that what they are entering is unambiguously a license expression, -with all the false positive and false negative issues as above. - -Therefore, for these reasons, we reject this here in favor of -the reserved string value of the ``license`` key. - - Source metadata ``license-files`` key ------------------------------------- From 5469b1af1a451a889ba0091e1b4aed11b08f87a3 Mon Sep 17 00:00:00 2001 From: Karolina Surma Date: Thu, 4 Jul 2024 16:56:44 +0200 Subject: [PATCH 3/6] Change the deprecation policy around classifiers --- peps/pep-0639.rst | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/peps/pep-0639.rst b/peps/pep-0639.rst index 71d11e16984..1bac2bfb5ad 100644 --- a/peps/pep-0639.rst +++ b/peps/pep-0639.rst @@ -451,22 +451,18 @@ in the ``Classifier`` :term:`Core Metadata field` (`described in the Core Metadata specification `__) is deprecated and replaced by the more precise ``License-Expression`` field. -If the ``License-Expression`` field is present, build tools SHOULD and -publishing tools MUST raise an error if one or more license classifiers +If the ``License-Expression`` field is present, build tools MAY raise an error +if one or more license classifiers is included in a ``Classifier`` field, and MUST NOT add such classifiers themselves. -Otherwise, if this field contains a license classifier, build tools MAY -and publishing tools SHOULD issue a warning informing users such classifiers +Otherwise, if this field contains a license classifier, +tools MAY issue a warning informing users such classifiers are deprecated, and recommending ``License-Expression`` instead. For compatibility with existing publishing and installation processes, the presence of license classifiers SHOULD NOT raise an error unless ``License-Expression`` is also provided. -For all newly-uploaded distributions that include a -``License-Expression`` field, the `Python Package Index (PyPI) `__ MUST -reject any that also specify any license classifiers. - New license classifiers MUST NOT be `added to PyPI `__; users needing them SHOULD use the ``License-Expression`` field instead. License classifiers may be removed from a new version of the specification From 3e7d44f411358ea596c80c1ecbe765206b592954 Mon Sep 17 00:00:00 2001 From: Karolina Surma Date: Wed, 17 Jul 2024 11:37:59 +0200 Subject: [PATCH 4/6] Flatten the value of the license-files key, only globs are specified --- peps/pep-0639.rst | 74 ++++++++++------------------- peps/pep-0639/appendix-examples.rst | 24 +++++----- 2 files changed, 38 insertions(+), 60 deletions(-) diff --git a/peps/pep-0639.rst b/peps/pep-0639.rst index 1bac2bfb5ad..25736265115 100644 --- a/peps/pep-0639.rst +++ b/peps/pep-0639.rst @@ -520,87 +520,62 @@ paths in the project source tree relative to ``pyproject.toml`` to file(s) containing licenses and other legal notices to be distributed with the package. It corresponds to the ``License-File`` fields in the Core Metadata. -Its value is a table, which if present MUST contain one of two optional, -mutually exclusive subkeys, ``paths`` and ``globs``; if both are specified, -tools MUST raise an error. Both are arrays of strings; the ``paths`` subkey -contains verbatim file paths, and the ``globs`` subkey valid glob patterns, -which MUST be parsable by the ``glob`` `module `__ in the -Python standard library. - +Its value is an array of strings which MUST contain valid glob patterns, +as specified below. +The glob patterns MAY contain special glob characters: ``*``, ``?``, ``**`` +and character ranges: ``[]``, and tools MUST support them. Path delimiters MUST be the forward slash character (``/``), and parent directory indicators (``..``) MUST NOT be used. Tools MUST assume that license file content is valid UTF-8 encoded text, and SHOULD validate this and raise an error if it is not. -If the ``paths`` subkey is a non-empty array, build tools: - -- MUST treat each value as a verbatim, literal file path, and - MUST NOT treat them as glob patterns. - -- MUST include each listed file in all distribution archives. - -- MUST NOT match any additional license files beyond those explicitly - statically specified by the user under the ``paths`` subkey. +Literal paths (e.g. ``LICENSE``) are treated as valid globs which means they +can also be defined. -- MUST list each file path under a ``License-File`` field in the Core Metadata. +To achieve better portability, the filenames to match should only contain +the alphanumeric characters, underscores (``_``), hyphens (``-``) +and dots (``.`` - for extensions). -- MUST raise an error if one or more paths do not correspond to a valid file - in the project source that can be copied into the distribution archive. - -If the ``globs`` subkey is a non-empty array, build tools: +Build tools: - MUST treat each value as a glob pattern, and MUST raise an error if the pattern contains invalid glob syntax. -- MUST include all files matched by at least one listed pattern in all +- MUST include all files matched by a listed pattern in all distribution archives. -- MAY exclude files matched by glob patterns that can be unambiguously - determined to be backup, temporary, hidden, OS-generated or VCS-ignored. - - MUST list each matched file path under a ``License-File`` field in the Core Metadata. -- SHOULD issue a warning and MAY raise an error if no files are matched. - -- MAY issue a warning if any individual user-specified pattern +- MUST raise an error if any individual user-specified pattern does not match at least one file. -If the ``license-files`` key is present, and the ``paths`` or ``globs`` subkey +If the ``license-files`` key is present and is set to a value of an empty array, then tools MUST NOT include any license files and MUST NOT raise an error. - Examples of valid license files declaration: .. code-block:: toml [project] - license-files = { globs = ["LICEN[CS]E*", "AUTHORS*"] } + license-files = ["LICEN[CS]E*", "AUTHORS*"] [project] - license-files.paths = ["licenses/LICENSE.MIT", "licenses/LICENSE.CC0"] + license-files = ["licenses/LICENSE.MIT", "licenses/LICENSE.CC0"] [project] - license-files = { paths = [] } + license-files = ["LICENSE.txt", "licenses/*"] [project] - license-files.globs = [] + license-files = [] Examples of invalid license files declaration: .. code-block:: toml [project] - license-files.globs = ["LICEN[CS]E*", "AUTHORS*"] - license-files.paths = ["LICENSE.MIT"] - -Reason: license-files.paths and license-files.globs are mutually exclusive. - -.. code-block:: toml - - [project] - license-files = { paths = ["..\LICENSE.MIT"] } + license-files = ["..\LICENSE.MIT"] Reason: ``..`` must not be used. ``\`` is an invalid path delimiter, ``/`` must be used. @@ -609,7 +584,7 @@ Reason: ``..`` must not be used. .. code-block:: toml [project] - license-files = { globs = ["LICEN{CSE*"] } + license-files = ["LICEN{CSE*"] Reason: "LICEN{CSE*" is not a valid glob. @@ -638,7 +613,7 @@ the ``license-files`` key instead. If the specified license ``file`` is present in the source tree, build tools SHOULD use it to fill the ``License-File`` field in the core metadata, and MUST include the specified file -as if it were specified in a ``license-file.paths`` field. +as if it were specified in a ``license-file`` field. If the file does not exist at the specified path, tools MUST raise an informative error as previously specified. @@ -725,9 +700,9 @@ and license classifiers retain backwards compatibility. A removal is left to a future PEP and a new version of the Core Metadata specification. Specification of the new ``License-File`` Core Metadata field and adding the -files in the distribution codifies the existing practices of many packaging -tools. It is designed to be largely backwards-compatible with their existing -use of that field. The new ``license-files`` key in the ``[project]`` table of +files in the distribution is designed to be largely backwards-compatible with +the existing use of that field in many packaging tools. +The new ``license-files`` key in the ``[project]`` table of ``pyproject.toml`` will only have an effect once users and tools adopt it. This PEP specifies that license files should be placed in a dedicated @@ -781,7 +756,8 @@ If an invalid ``License-Expression`` is used, the users will not be able to publish their package to PyPI and an error message will help them understand they need to use SPDX identifiers. It will be possible to generate a distribution with incorrect license metadata, -but not to publish one on PyPI or any other index server that enforces ``License-Expression`` validity. +but not to publish one on PyPI or any other index server that enforces +``License-Expression`` validity. For authors using the now-deprecated ``License`` field or license classifiers, packaging tools may warn them and inform them of the replacement, ``License-Expression``. diff --git a/peps/pep-0639/appendix-examples.rst b/peps/pep-0639/appendix-examples.rst index ed6d97165ea..68d8b5d7170 100644 --- a/peps/pep-0639/appendix-examples.rst +++ b/peps/pep-0639/appendix-examples.rst @@ -127,29 +127,30 @@ Putting it all together, our ``setup.cfg`` would be: setuptools/_vendor/packaging/LICENSE.APACHE setuptools/_vendor/packaging/LICENSE.BSD -In the ``[project]`` table of ``pyproject.toml``, with license files -specified explicitly via the ``paths`` subkey, this would look like: +In the ``[project]`` table of ``pyproject.toml``, license files +can be specified via glob patterns: .. code-block:: toml [project] license = "MIT AND (Apache-2.0 OR BSD-2-Clause)" - license-files.paths = [ - "LICENSE", - "setuptools/_vendor/LICENSE", - "setuptools/_vendor/LICENSE.APACHE", - "setuptools/_vendor/LICENSE.BSD", + license-files = [ + "LICENSE*", + "setuptools/_vendor/LICENSE*", ] -Or alternatively, matched via glob patterns, this could be: +Or alternatively, they can be specified explicitly (paths will be interpreted +as glob patterns): .. code-block:: toml [project] license = "MIT AND (Apache-2.0 OR BSD-2-Clause)" - license-files.globs = [ - "LICENSE*", - "setuptools/_vendor/LICENSE*", + license-files = [ + "LICENSE", + "setuptools/_vendor/LICENSE", + "setuptools/_vendor/LICENSE.APACHE", + "setuptools/_vendor/LICENSE.BSD", ] With either approach, the output Core Metadata in the distribution @@ -211,6 +212,7 @@ Some additional examples of valid ``License-Expression`` values: License-Expression: GPL-3.0-only WITH Classpath-Exception-2.0 OR BSD-3-Clause License-Expression: LicenseRef-Public-Domain OR CC0-1.0 OR Unlicense License-Expression: LicenseRef-Proprietary + License-Expression: LicenseRef-Custom-License .. _packaginglicense: https://github.com/pypa/packaging/blob/21.2/LICENSE From 83826758e208fc565743112474594df8d8199f38 Mon Sep 17 00:00:00 2001 From: Karolina Surma Date: Wed, 17 Jul 2024 16:13:44 +0200 Subject: [PATCH 5/6] Update the Rejected ideas to match the current license-files proposal --- peps/pep-0639/appendix-rejected-ideas.rst | 165 ++++------------------ 1 file changed, 25 insertions(+), 140 deletions(-) diff --git a/peps/pep-0639/appendix-rejected-ideas.rst b/peps/pep-0639/appendix-rejected-ideas.rst index 9f614e40d69..d66567cf0ac 100644 --- a/peps/pep-0639/appendix-rejected-ideas.rst +++ b/peps/pep-0639/appendix-rejected-ideas.rst @@ -232,17 +232,30 @@ Alternatives considered for the ``license-files`` key in the path/glob type handling. -Add a ``type`` subkey to ``license-files`` -'''''''''''''''''''''''''''''''''''''''''' - -Instead of defining mutually exclusive ``paths`` and ``globs`` subkeys -of the ``license-files`` ``[project]`` table key, we could -achieve the same effect with a ``files`` subkey for the list and -a ``type`` subkey for how to interpret it. However, it offers no -real advantage in exchange for requiring more keystrokes, -increased complexity, as well as less flexibility in allowing both, -or another additional subkey in the future, as well as the need to bikeshed -over the subkey name. Therefore, it was rejected. +Define mutually exclusve ``paths`` and ``globs`` subkeys to ``license-files`` +''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' + +A previous draft of the PEP specified mutually exclusive ``paths`` and +``globs`` subkeys of the ``license-files`` ``[project]`` table key. +This was proposed to achieve the maximum clarity of the defined values for +both users and tools. +Allowing license files to be specified as literal paths would avoid edge cases, +such as those containing glob characters +(or those confusingly similar to them, as described in :pep:`672`). + +However, this approach introduces an extra level of nesting - in the very same +way that PEP 639 removes from the ``license`` key. This creates more burden +on project authors who need to disambiguate and choose one or the other +approach to specify their license files location. It was pointed out that +it is easily possible to incorrectly assume that paths also support +globs. + +Therfore, it was decided against this approach in favor of a flat array value +which simplifies the specification and implementation, +and more closely matches the configuration format of existing tools. +The PEP recommends not to use other than alphanumerical symbols and dot +(``.``) in the filenames to not create confusion +when interpreting glob patterns. Only accept verbatim paths @@ -267,138 +280,10 @@ legal file, creating the package illegal to distribute. Tools can still determine the files to be included, based only on the glob patterns the user specified and the filenames in the package, without installing it, executing its code or even -examining its files. Furthermore, tools are explicitly allowed to warn -if specified glob patterns don't match any files. +examining its files. And, of course, sdists, wheels and others will have the full static list of files specified in their distribution metadata. -Perhaps most importantly, this would also exclude the currently specified -default value widely used by the most popular tools, and thus -be a major break to backward compatibility. -And of course, authors are welcome to specify their license -files explicitly via the ``paths`` table subkey, once they are aware of it and -find it suitable for their project. - - -Only accept glob patterns -''''''''''''''''''''''''' - -Conversely, all ``license-files`` strings could be treated as glob patterns. -This would slightly simplify the spec and implementation, avoid an extra level -of nesting, and more closely match the configuration format of existing tools. - -However, for the cost of a few characters, it ensures users are aware -whether they are entering globs or verbatim paths. Furthermore, allowing -license files to be specified as literal paths avoids edge cases, such as those -containing glob characters (or those confusingly or even maliciously similar -to them, as described in :pep:`672`). - -Including an explicit ``paths`` value ensures that the resulting -``License-File`` metadata is correct, complete and purely static in the -strictest sense of the term, with all license paths explicitly specified -in the ``pyproject.toml`` file, guaranteed to be included and with an early -error if any are missing. This is not practical to do, at least without -serious limitations for many workflows, if we must assume the items -are glob patterns rather than literal paths. - -This allows tools to locate them and know the exact values of the -``License-File`` Core Metadata fields without having to traverse the -source tree of the project and match globs, potentially allowing -more reliable programmatic inspection and processing. - -Therefore, given the relatively small cost and the significant benefits, -this approach was not adopted. - - -Infer whether paths or globs -'''''''''''''''''''''''''''' - -It was considered whether to simply allow specifying an array of strings -directly for the ``license-files`` key, rather than making it a table with -explicit ``paths`` and ``globs``. This would be simpler and avoid -an extra level of nesting, and more closely match the configuration format -of existing tools. However, it was ultimately rejected in favor of separate, -mutually exclusive ``paths`` and ``globs`` table subkeys. - -In practice, it only saves six extra characters in the ``pyproject.toml`` -(``license-files = [...]`` vs ``license-files.globs = [...]``), but allows -the user to explicitly declare their intent and serves as an unambiguous -indicator for tools to parse them as globs rather than verbatim paths. - -This, in turn, allows for clearly specified tool -behaviors for each case, many of which would be unreliable or impossible -without it and -behave more intuitively overall. These include, with ``paths``, -guaranteeing that each specified file is included and immediately -raising an error if one is missing, and with ``globs``, checking glob syntax, -excluding unwanted backup, temporary, or other such files, -and optionally warning if a glob doesn't match any files. -This also avoids edge cases (e.g. paths that contain glob characters) and -reliance on heuristics to determine interpretation. - - -.. _639-license-files-allow-flat-array: - -Also allow a flat array value -''''''''''''''''''''''''''''' - -Initially, after deciding to define ``license-files`` as a table of ``paths`` -and ``globs``, thought was given to making a top-level string array under the -``license-files`` key mean one or the other (probably ``globs``, to match most -current tools). This is slightly shorter, indicates to -the users which one is a preferred one, and allows a cleaner handling of -the empty case. - -However, this only saves six characters in the best case, and there -isn't an obvious choice. - -Flat may be better than nested, but in the face of ambiguity, users -may not resist the temptation to guess. Requiring users to explicitly specify -one or the other ensures they are aware of how their inputs will be handled, -and is more readable for others. It also makes -the spec and tool implementation slightly more complicated, and it can always -be added in the future, but not removed without breaking backward -compatibility. And finally, for the "preferred" option, it means there is -more than one obvious way to do it. - -Therefore, per :pep:`20`, the Zen of Python, this approach is rejected. - - -Allow both ``paths`` and ``globs`` subkeys -'''''''''''''''''''''''''''''''''''''''''' - -Allowing both ``paths`` and ``globs`` subkeys to be specified under the -``license-files`` table was considered, as it could potentially allow -more flexible handling for particularly complex projects. - -However, given the existing proposed approach already matches or exceeds the -capabilities of those offered in tools' config files, there isn't -clear demand for this, and it adds a large -amount of complexity in tool implementations and ``pyproject.toml`` -for relatively minimal gain. - -There would be many more edge cases to deal with, such as how to handle files -matched by both lists, and it conflicts with the current -specification for how tools should behave, such as when -no files match. - -Like the previous, if there is a clear need for it, it can be always allowed -in the future in a backward-compatible manner, -while the same is not true of disallowing it. -Therefore, it was decided to require the two subkeys to be mutually exclusive. - - -Rename ``paths`` subkey to ``files`` -'''''''''''''''''''''''''''''''''''' - -Initially, the name ``files`` was considered instead of the ``paths`` for the -subkey of ``license-files`` table. However, ``paths`` was ultimately -chosen to avoid duplication between -the table name (``license-files``) and the subkey name (``files``), i.e. -``license-files.files = ["LICENSE.txt"]``. It made it seem like -the preferred subkey when it was not, and didn't describe the format of the -string entry similarly to the existing ``globs``. - Use a default value for ``license-files`` if not specified '''''''''''''''''''''''''''''''''''''''''''''''''''''''''' From dddf688fbd7ee1139f250cd426a59e7067cc7e5d Mon Sep 17 00:00:00 2001 From: Karolina Surma <33810531+befeleme@users.noreply.github.com> Date: Thu, 25 Jul 2024 13:39:01 +0200 Subject: [PATCH 6/6] Update peps/pep-0639.rst MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Miro Hrončok --- peps/pep-0639.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/peps/pep-0639.rst b/peps/pep-0639.rst index 25736265115..433045b6437 100644 --- a/peps/pep-0639.rst +++ b/peps/pep-0639.rst @@ -534,7 +534,7 @@ can also be defined. To achieve better portability, the filenames to match should only contain the alphanumeric characters, underscores (``_``), hyphens (``-``) -and dots (``.`` - for extensions). +and dots (``.``). Build tools: