With the addition of `project.dependencies` includes from Dependency
Groups, additions are warranted in the "How to Teach This" section of
the PEP.
Firstly, it is now useful to mention the similarity between a
dependency group and an old-style `setup.py` which reads either as
setup(install_requires=_read_helper("requirements.txt"), ...)
or else as
requirements = ["foo", ...]
...
setup(install_requires=requirements, ...)
Secondly, discussion of the interfaces for Dependency Groups adds a
dimension to the document. For tool authors, this clarifies that
allowing `project.dependencies` to use includes is necessary for
build backends to declare support, but that there are no other formal
requirements for tools. They will have to decide on interfaces -- and
therefore what it means to support Dependency Groups -- for
themselves. The spec provides only for the data. Additionally, the
consequences for users, and the fact that this allows tools to define
and enforce additional rules (which they must document) are called out
explicitly.
Implicitly, this hints that it is possible for tools to have
conflicting requirements, so that it may become possible for toolA and
toolB to have incompatible or at least orthogonal needs. Due to the
relatively low risk of outright conflicts, and the ability of
responsible tool maintainers to work through such cases if they do
arise, this is not addressed at length.
PEP 735 is expanded here to allow `project.dependencies` and
`project.optional-dependencies` to use Dependency Group Includes. This
allows for includes which help satisfy the use-cases described by the
`--only-deps` pip use-cases.
The changes for this are various:
- support for these includes is added to the rationale section
- a new use case is added, aligned with the `--only-deps` use case
- the spec section is updated to list changes to the `project` table
- backwards compatibility is extended significantly to address
repackaging concerns as well as dependency analyzers[^1]
- "how to teach this" is also extended to note compatibility and
repackaging issues
- rejected ideas has added an item on `[build-system.requires]`
[^1]: It may be overstatement to say these concerns are addressed.
They are considered and not dismissed, but it is not clear that any
choices can be made in the spec to address these issues other than to
inform users.
Additionally, one unrelated change is included: the spec now notes
explicitly that extra names and dependency group names can overlap
(this was already possible, implicitly) and instructs tools to decide
on their own how to handle that if they present dependency groups and
extras via a uniform interface.
Co-authored-by: Brett Cannon <brett@python.org>
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.
Refine "non-standard" phrasing in PEP 735
One of the Poetry maintainers noted tha the current phrasing could be
read as a negative take on `poetry` and `pdm` using "non-standard"
data.
At the same time, it's important to be clear that the problem being
solved here is not adequately solved by the existing tools due to the
lack of an existing underlying standard.
This rephrasing tries to balance these two concerns, describing the
current behaviors as 'tool specific' and focusing on "standardization"
(positive) rather than "non-standardization" (negative).
- Minor corrections / typo fixes
- Use a ref role for `use_cases` link. As currently written, it
renders incorrectly to a relative link to a `use_cases` page.
- Fix header style for Use Cases Appendix
- Add an explicit Compatibility section to Rationale
Future compatibility and designing the Dependency Groups data to be
extensible is a particular area of concern within the PEP. Although it
is addressed to some degree in the Specification, this small note in
the Rationale clarifies that compatibility with spec extensions is a
---------
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
- Remove the PEP 723 use-case
- Change to non-normalized names which require normalization
- Update the reference implementation to normalize
- Clarify the meaning of an Include
- Forbid cycles in includes
- Add a section on validation and compatibility which clearly defines
future-compatible behavior
- Remove 'include list' from open issues
- Add 'includes of `[project]` tables' to open issues
The major changes are as follows:
- remove support for path dependencies (!)
- include a reference implementation
- move 'use cases' into appendix
- rephrase position vis-a-vis Poetry and PDM, and move details
of those tools into an appendix
- include more example data throughout
- explicitly address the lack of standardization around "reserved
names" for Dependency Groups in several places
This revision should be shorter as well. Some redundant and wordy
sections have been struck or rewritten.
---------
Co-authored-by: Brett Cannon <brett@python.org>
Stephen Rosen
Sviatoslav Sydorenko (Святослав Сидоренко)