Basically, it needs a transition plan, because it is a change to the definition of the semantics of the [project] table. Unfortunately, PEP 621 didn’t specify any versioning for the [project] table, so there’s no clear solution here (this would have been a problem anyway when core metadata changes - so it’s not specific to this PEP).
Because of the versioning issue, it may be too much to introduce into this PEP. Also, it does mean that future proposals to add things like path based dependencies would have to address the fact that you can’t include a group that has those extensions in it, in [project.dependencies].
So yes, I think it might be too much of a can of worms.
Having said that, I’m still far more happy with something like this, than with encouraging backends to do something similar via a custom extension and dynamic dependencies.
And while being able to have an “extended form”[1] that says “include the project runtime dependencies” or “include this extra that the project defines” would be an expedient solution, I don’t really like it as it feels like the information is flowing in the wrong direction, somehow…
We should come up with a term for “dependencies that can go in a dependency group which aren’t PEP 508 requirements”, even though we’re not allowing any such thing right now, just so we can talk about them easily!] that ↩︎