If we had versioning on the table, and we were proposing the introduction of a new version (e.g. 1.0 → 1.1), we might hear some flavor of the same argument. That introducing a new version will break some tool which doesn’t support v1.1. That’s the context in which I read an argument against adding some new syntax simply because an older tool will break upon seeing it.
Perhaps that was an unfairly ungenerous reading by me of @EpicWink’s comment though. Sorry for that!
I’m not convinced – accepting the lack of a version as a simple fact of life for the purposes of this discussion – that we shouldn’t expand the definition of project.dependencies to allow it to refer back to Dependency Groups.
My intention in making that statement was that the dependency list is expanded in PKG-INFO. But I’m not sure that backends are required to populate Requires-Dist fully. Perhaps this would need to be included as an expectation.
I very much don’t like the idea of requiring that backends edit pyproject.toml before including it in an sdist. My overarching goal is to ensure that the Dependency Groups of a package are never considered part of its public interface either when being installed or once installed.
I need to think about the implications here a bit more, in terms of what I would expect from a built sdist (I have very clear expectations about the wheel, less so about the sdist).
This is what I’ve been considering, but I’m a bit uncomfortable with the resulting state for package authors who have some legitimate need for dynamic dependencies.
They’re left unable to integrate with Dependency Groups because of the requirement that the data is static.
If we allow the inclusion to run in the other direction, then there’s no such conflict. So I see it as a better place to end up, even though it might be more difficult to get there.
I generally agree that it would be nice to support inclusion of project.dependencies in a dependency group though.
I don’t think this is a complete argument in its own right. Sometimes you try to do this and find a 2000 LOC setup.py file, after all. 
Truthfully, a part of me wants includes to work in both directions, with the constraint that the data has to be static for inclusion in a Dependency Group (but not vice-versa; a dynamic dependency list could include a Dependency Group).
That offers users the choice of how they want to structure these data, allows us to include something today (inclusions of static dependency lists in groups) and lets users potentially restructure to reverse the relationship in the future if they so choose.
Probably this is a sign that my thinking on this subject is not sufficiently mature yet. I’m certainly not ready to make any change to the PEP to mention inclusions from or of [project.dependencies].
I understand that the topic has arisen naturally here, but can we split any discussion of versioning [project] into a separate thread? I think that will be helpful both in order to keep this thread focused on Dependency Groups and to enable more people to engage on the versioning topic.