PEP 735: rename 'include' to 'include-group' (#3836)
This changes the key used in PEP 735 Dependency Group Includes to be 'include-group'. Per feedback, and related to discussions about the future direction of the PEP, this key will be less ambiguous when Dependency Group Includes appear in other contexts and tables.
This commit is contained in:
parent
ae5512c91d
commit
e947a9dcb0
|
@ -130,7 +130,7 @@ example:
|
|||
test = ["pytest>7", "coverage"]
|
||||
|
||||
There are a number of use cases for ``requirements.txt`` files which require
|
||||
data which cannot be expressed in :pep:`508` dependency specifiers. Such
|
||||
data which cannot be expressed in :pep:`508` dependency specifiers. Such
|
||||
fields are not valid in Dependency Groups. Including many of the data and
|
||||
fields which ``pip`` supports, such as index servers, hashes, and path
|
||||
dependencies, requires new standards. This standard leaves room for new
|
||||
|
@ -252,16 +252,16 @@ Dependency Group Include
|
|||
A Dependency Group Include includes the dependencies of another Dependency
|
||||
Group in the current Dependency Group.
|
||||
|
||||
An include is defined as a table with exactly one key, ``"include"``, whose
|
||||
value is a string, the name of another Dependency Group.
|
||||
An include is defined as a table with exactly one key, ``"include-group"``,
|
||||
whose value is a string, the name of another Dependency Group.
|
||||
|
||||
For example, ``{include = "test"}`` is an include which expands to the
|
||||
For example, ``{include-group = "test"}`` is an include which expands to the
|
||||
contents of the ``test`` Dependency Group.
|
||||
|
||||
Includes are defined to be exactly equivalent to the contents of the named
|
||||
Dependency Group, inserted into the current group at the location of the include.
|
||||
For example, if ``foo = ["a", "b"]`` is one group, and
|
||||
``bar = ["c", {include = "foo"}, "d"]`` is another, then ``bar`` should
|
||||
``bar = ["c", {include-group = "foo"}, "d"]`` is another, then ``bar`` should
|
||||
evaluate to ``["c", "a", "b", "d"]`` when Dependency Group Includes are expanded.
|
||||
|
||||
Dependency Group Includes may specify the same package multiple times. Tools
|
||||
|
@ -274,7 +274,7 @@ include. For example, given the following table:
|
|||
group-a = ["foo"]
|
||||
group-b = ["foo>1.0"]
|
||||
group-c = ["foo<1.0"]
|
||||
all = ["foo", {include = "group-a"}, {include = "group-b"}, {include = "group-c"}]
|
||||
all = ["foo", {include-group = "group-a"}, {include-group = "group-b"}, {include-group = "group-c"}]
|
||||
|
||||
The resolved value of ``all`` SHOULD be ``["foo", "foo", "foo>1.0", "foo<1.0"]``.
|
||||
Tools should handle such a list exactly as they would handle any other case in
|
||||
|
@ -299,7 +299,7 @@ define four Dependency Groups: ``test``, ``docs``, ``typing``, and
|
|||
test = ["pytest", "coverage"]
|
||||
docs = ["sphinx", "sphinx-rtd-theme"]
|
||||
typing = ["mypy", "types-requests"]
|
||||
typing-test = [{include = "typing"}, {include = "test"}, "useful-types"]
|
||||
typing-test = [{include-group = "typing"}, {include-group = "test"}, "useful-types"]
|
||||
|
||||
Note that none of these Dependency Group declarations implicitly install the
|
||||
current package, its dependencies, or any optional dependencies.
|
||||
|
@ -444,7 +444,7 @@ The output is therefore valid ``requirements.txt`` data.
|
|||
Requirement(item)
|
||||
realized_group.append(item)
|
||||
elif isinstance(item, dict):
|
||||
if tuple(item.keys()) != ("include",):
|
||||
if tuple(item.keys()) != ("include-group",):
|
||||
raise ValueError(f"Invalid dependency group item: {item}")
|
||||
|
||||
include_group = _normalize_name(next(iter(item.values())))
|
||||
|
@ -1099,7 +1099,7 @@ library:
|
|||
test = ["pytest<8", "coverage"]
|
||||
typing = ["mypy==1.7.1", "types-requests"]
|
||||
lint = ["black", "flake8"]
|
||||
typing-test = [{include = "typing"}, "pytest<8"]
|
||||
typing-test = [{include-group = "typing"}, "pytest<8"]
|
||||
|
||||
Note that none of these implicitly install the library itself.
|
||||
It is therefore the responsibility of any environment management toolchain to
|
||||
|
@ -1136,8 +1136,8 @@ Consider the following more elaborate configuration:
|
|||
|
||||
[dependency-groups]
|
||||
main = ["numpy", "pandas", "matplotlib"]
|
||||
scikit = [{include = "main"}, "scikit-learn==1.3.2"]
|
||||
scikit-old = [{include = "main"}, "scikit-learn==0.24.2"]
|
||||
scikit = [{include-group = "main"}, "scikit-learn==1.3.2"]
|
||||
scikit-old = [{include-group = "main"}, "scikit-learn==0.24.2"]
|
||||
|
||||
This defines ``scikit`` and ``scikit-old`` as two similar variants of the
|
||||
common suite of dependencies, pulling in different versions of ``scikit-learn``
|
||||
|
|
Loading…
Reference in New Issue