PEP 735: Dependency Groups in pyproject.toml

I don’t know if @sirosen has had the time to update the draft. My reading of this post from earlier in the thread is that the include-group object would be allowed in the dependencies and optional-dependencies (i.e. extras) tables.

As mentioned in that post, it’s something that is open to discussion. But my understanding is that this would be in an upcoming revision (whenever that may be).


Yep, that’s my intent! I’ve had a ton of work and personal stuff hit this year (not all bad, but just really busy) and haven’t made it back to this PEP yet, but I definitely will.
The next draft, which I intend to be the final significant revision, will include syntax for referring to dependency groups from the project table. And I’ll really need to work on sections like How to Teach This and talk about the tool impact. The spec change is small, but I recognize that the impact is large.

To answer the basic question of “why dependency groups rather than a single dev dependency group”, I think my own experience as a library and application maintainer is that these already exist. Either they are explicit or implicit, but they’re not a new idea. As others have said, there are a mix of technical and organizational benefits to grouping dependencies.
I also know that I have had the experience of needing conflicting or distinct dependency groups for different purposes – in tox, this is often expressed using factors.

Depriving users of a vocabulary for expressing these things makes their lives more complicated when they have need of them. Dependency Groups make the easy cases a little more complex in exchange for adding no new concepts when users outgrow those usages.


I really like this idea, but I’d like to raise a question. Why creating a new table [dependency-groups] when it could just be []? My reasoning:

  1. It’s more or less compliant with what workflow tools have implemented so far (including people existent usages and expectations).
  2. It can still have groups as much as [project.optional-dependencies] does.
  3. It’s symmetric to [project.optional-dependencies] and is clearer (dependency-group) as @charliermarsh pointed out might look like the project’s optional dependencies.
  4. The dev-depencencies name is clear: users already saw them if they use tools like poetry rye and PDM. Usually, people add optional dependency groups named test or dev or docs already.

I’d argue the table should be below project because this is what these dependencies are: the project’s development dependencies (not the build system or something else).

For me the important thing is that this is a general mechanism, and not tied to just being for development dependencies. So I prefer the naming as it is in the PEP. Yes, it can (and will) be used for development dependencies, but if you want it for something else we don’t need to make another standard (or misuse dev-dependencies).


I understand your point! But fail to see other possible use-cases. Is this just to “future proof” dependency groups? (Honest question here.) There’s also the draft for PEP725 that is about “other” dependencies that might be necessary.

You can view this as extras for apps if you want. But I also don’t expect people to come to this with an empty table; the groups themselves will probably make it clearer what stuff is for. And the docs around [dependency-groups] should make it clear it can be used for dev-related purposes, but that’s not it’s exclusive domain.


1 Like

The simplest use-case for dependency groups is just “to group my dependencies” in a complex project. They don’t have to be for development, they don’t have to be optional, they don’t have to be extra. It’s a group of dependencies.


The PEP explicitly calls out why it is not a subtable of [project] as part of the rejected alternatives: Why is the table not named…

Supporting non-package projects is one of the goals here.

You mean you failed to see the Use Cases Appendix, right? :wink:

If this section isn’t prominent enough in the PEP, please say so. Maybe it can be called out earlier (e.g. in the abstract with minimal fuss)

I need to break through the psychological wall between me and serious work this PEP, so there will be some smaller scale edits in the short term. Right now I’m opening a branch to switch include = ... to include-group = ...