Is the motivation of this purely so you you can install the packages in Dev without installing sunpy. I don't really get it.

I think there are negatives here to be honest, like the pip version, it's not ideal to either require a newer python than the package requires or have people update pip manually.

But even when that is resolved when 3.13 is dropped:

The syntax for installing dev deps is now different from the extras which seems really unfriendly, like hey you want the maps optional deps do this, your ant the docs optional deps do this totally different syntax.

I guess that is partly mitigated by the presence of [all] which pulls in Dev and docs?

Although damn the syntax for defining meta groups is horrendous.

The point is to hide dev-only dependencies from end users.
Since only devs have access to dependency groups, requiring a new-ish version of pip is much more reasonable than if it were user-visible.

I guess that is partly mitigated by the presence of [all] which pulls in Dev and docs?

extras (optional-dependencies) cannot reference dependency groups; it would defeat the purpose.

Then the motivation is beyond my ken.

I don't see end users inspecting pyproject and being at all confused.

I don't really think the pip version is a problem, I just meant that even if that wasn't an issue then all I foresee this just making a bunch of people typing pip install -e .[dev] then getting an error, checking the pyproject, having no idea how to install them and googling it. Then repeating those steps again next month.

A dev extra sn't universal but it is pretty common a pattern.

A dev extra sn't universal but it is pretty common a pattern.

Until PEP 725 was accepted the only alternatives were tool-specific rather than standard. tox had way to do this, pip had a different one, uv and I guess poetry (probably pdm too) had their own version of this. This is now supported by most tools (probably not conda, but it already never supported extras or editable installs).
Users don't typically inspect pyproject.toml (heck, it doesn't typically reach their installs), but many tools digest optional dependencies and advertise them (see pypi.org or pypistats.org). Exposing dev-only dependencies there only creates noise around the extras users actually want or need, hindering discoverability. Any user-visible traits also have a way to be adopted downstream, but no-body wants or should have to support that.

I didn't think project.optional-dependencies was tool specific though, it's been standard for years and years (and all the package managers support it except conda which is weird as you say)

https://peps.python.org/pep-0631/

https://peps.python.org/pep-0621/

I meant alternatives that didn't leak dev-only details. That's precisely the trade off that made optional-dependencies preferable for many projects.