[dependency-groups]
coverage = ["coverage[toml]"]
test = ["pytest>7", {include-group = "coverage"}]
To me, this looks like it would be an excellent extension to project.optional-dependencies as well.
[project.optional-dependencies]
a = [
"foo>=3.9.0",
"bar>=4.12.2",
{ include-group = "b" }
]
b = ["baz>=13.9.4", "qux>=1.2.4"]
I’m aware of the self referential syntax:
[project.optional-dependencies]
a = ["foo>=3.9.0", "bar>=4.12.2", "mypackage[b]"]
b = ["baz>=13.9.4", "qux>=1.2.4"]
But I’m hesitant to use it because I couldn’t find any documentation for it on Python Packaging User Guide and I have no idea about the semantics. Should the self reference have a version constraint? Should it not? Something else I’m missing?
The self reference must be to the same version, since there’s no way to install two versions at once[1]. I don’t think adding a constraint could affect anything but it might break things.
So I don’t think include-group is needed–this is your solution.
If we added include-group to optional dependencies, I’d expect it to pull values in from dependency-groups. Which was in earlier drafts of the proposal! I removed it, then added it back, and then was finally convinced to remove it before submitting PEP 735 for consideration.
The self referential syntax works for all tools which I know of. There might be some slack in the specifications which we can tighten up, but that’s the right solution for optional dependencies, partly by default because it already works.
If you wanted include-group to allow you to pull dependency groups into the project table, I’d be willing to coauthor or help with a proposal, but I think it’s too soon – wait at least until pip 25.1 releases in a week and we see how that plays out. I think this is something which people will want sooner or later, but not introducing it until there’s more support for dependency groups will make the change less impactful for tool maintainers.