It was mainly group inclusion from the main project tables that concerned me (since it actively encouraged projects to break backwards compatibility).
So yeah, I think it’s fine to ignore that second point on my list - it was the first & third that really aren’t ready yet.
I have a PR in-flight for the PEP that makes some (hopefully final) changes.
There were some elements of feedback which I ultimately decided don’t belong in this document. I want to be clear about what is intentionally omitted, so that if I missed something else it can be caught.
I have decided not to describe requirements.in vs requirements.txt in the PEP text, not even in “How to Teach This”.
requirements.txt files have been supported by pip from the earliest versions I have seen (I checked it out in the pypa/pip repo and it dates back to the first commit there, when it was still named pyinstall, 16 years ago!). They’re pretty well understood by the community to refer to either pinned or unpinned dependencies, and in fact it’s a pretty recent development that they’re being used for pinning in a wide variety of projects.
I understand that some class of users are frequently confused about pinned vs unpinned dependencies, but I just don’t think it’s the place of this PEP to even try to resolve that confusion. I do not believe that calling these files requirements.txt adds to that confusion, as their usage and support in pip and various ecosystem tools (e.g., I can reference them in my readthedocs config) is well established.
I misunderstood this at first as saying that uv supports use of [project.optional-dependencies] with an incomplete [project] table. @konstin corrected me on my PR (thanks again for this!), and so I’ve picked up @zanie’s suggested text and made a small addition:
Because
extrasare package metadata, they are not guaranteed to be
statically defined and may require a build system to resolve.
Furthermore, definition of a[project.optional-dependencies]indicates to
many tools that a project is a package, and may drive tool behaviors such as
validation of the[project]table.
I think that covers our bases pretty well.
The last major thing to address is how a Dependency Group could indicate that it includes the package itself.
IMO, the best solution for this is to standardize expression of path dependencies. Inclusion of the current package could then simply be expressed as . or foo_pkg @ .[1] or whatever other syntax is determined to be acceptable for paths.
I therefore intend to omit any version of this, including {include-project = true}, etc., from the PEP. Otherwise, we would have two ways of expressing the same thing.
I’ll add it to the rejected ideas section when I have a minute to write up this position.
similar to a package URI, with name required ↩︎
Note that a PEP can also include a “Deferred Ideas” section to separate the “Valid question with no clear answer for right now” ideas from the “We should never do this” ideas.
No “Rejected Ideas” section in a PEP is ever fully binding on future PEPs, but the question of previous rejection never even comes up if the previous PEP just lists the idea as being out of scope for that particular proposal rather than listing it as an idea that is considered genuinely problematic.
The final edit PRs have landed, and I will submit PEP 735 early next week unless there is new late-breaking feedback which merits a delay.
Just an update, @sirosen contacted me by private message to request a pronouncement on this PEP. I’ll be reviewing it over the next few days and will post my decision here.
Would this be a good point/place to mention a desire for having non-built distribution scripts (like [project.scripts] but tailored for development or something not bound to the package upon install)?
I do not wish to increase scope as I have similar desire to see this approved, but the area is the same-ish.
The tale of this PEP has been, in summary, “Smaller, narrower, more focused!”
Almost every step of the way has been a matter of stripping it back further and further.
I think it’s much too late to add anything significant to the scope of Dependency Groups. I would be very happy to discuss this topic more, especially if it builds on top of Dependency Groups, but would prefer to do it in a fresh thread. I’m not sure I understand what the use case is here – it may be related to PEP 723 Script Metadata?
I would be happy to discuss this elsewhere! Looking around, I’ve found A new PEP to specify dev scripts and/or dev scripts providers in pyproject.toml but am curious if more/any progress could be made given the very active state of packaging improvements and discussions lately.
Feel free to try and start a new topic to see if there’s interest in such a thing.
I have now reviewed this PEP (and the thread here - phew!) and I’m pleased to say that PEP 735 (Dependency Groups) is accepted 
Congratulations, @sirosen - this was a long, complex discussion and you handled it really well, keeping things on track without shutting down important debates. For a first PEP, it was a very impressive performance!
This is a very good point, and in my opinion was a key factor in the success of the PEP. It would have been very easy to try to support everything in one go, and end up with a complex specification with a bunch of incompletely understood edge cases. By deferring complex questions for future extensions, you’ve established a solid base for the feature without locking us out of further capabilities in future. That’s a useful lesson for authors of other PEPs to learn.
I should also have said - can you please update the PEP with the appropriate status updates, including marking it as Accepted and including a link to my acceptance post here?
Yep, I’ll put in the PR within the hour! 
Obviously I’m super happy!
So far, my little dependency-groups package is the only implementation I know of out on pypi.
But I aim change that. I’ll be going to various projects to discuss adding support.
Indeed, this was rather pleasant to follow. Good job @sirosen and everyone who participated.
Now, I am eager to see what people end up building on top of this…
P.S.: Damn! It took nearly a year, though… : D
I promise my next one will be faster. 
Almost all of it happened in two spurts. November 2023 - February 2024, and then the recent push. There was a long chunk of time with this in dormancy. So I think it looks worse on paper than it really was!
Congrats @sirosen!
Starting to implement this in uv already
I’ve already started taking this PEP into consideration in my next update for PEP 751.
I’ll start adding it to validation. Schema-store, validate-pyproject, pyproject-metadata’s not-yet-released checking, etc. I’m not sure how to add to nox yet, will factor into the the new nox.project features, I expect. Technically, since nox just allows you to load the pyproject.toml and process it yourself, it’s already “supported”.
I’m curious, what does this line imply?
- a package’s requirements (and extras) may depend upon Dependency Groups
I thought there was no sharing between extras and dependency groups? What does depend mean here?
Ooh, that’s a mistake! I assume that it’s acceptable to edit the PEP to remove that line, since it’s not supposed to be there. Should I just put in a PR?
That was in earlier drafts but got removed.
I can help out with schemastore. If you don’t beat me to it, I might put in a PR and @-mention you for review.
Yep, copyediting to fix errors post-acceptance is fine (one of the many perks of public version control).
Compared to some other changes, that’s more like “It didn’t even take a full year!”