[request] Support for `[dependency-groups]`

[Diogo-Rossi]

Please, implement the recently standardized [dependency-groups] table as defined in PEP 735

Related issue: #754

[funkyfuture]

i don't think that spamming the issue list with quasi redundant items is helpful in any regard.

[axel-kah]

Looking forward to #1922 being merged, so that I can write pyproject.toml files that work with uv sync and hatch env create and both pick up the dev dependencies from the same [dependency-groups] table.

[djcopley]

@axel-kah I made a hatch environment plugin that uses uv sync to create the hatch environments. See hatch-uvenv. It will allow you to use dependencies from the same [dependency-groups] table while 1922 is being reviewed. It also has the added benefit of respecting the uv.lock file when resolving dependencies.

[flying-sheep]

@ofek needs to weigh in here but I’d advocate for tighter integration with dependency groups.

They exist to be exactly what hatch’s env dependencies are, so I say we deprecate envs.$name.dependencies and envs.$name.features and add project.dependency-groups.$name as a blessed replacement for the former.

An example that uses features:

[project]
name = "foo"

[project.optional-dependencies]
testing = ["testing.postgresql"]  # Dependencies for our test utilities

[dependency-groups]
hatch-test = ["foo[testing]", "pytest"]

Here, hatch test should install our project in editable mode, and both pytest and testing.postgresql.

[ofek]

The example breaks down if you remove pytest; now you have a dependency group that only exists so you can reference what you want.

[djcopley]

I do really like the vision, but it kind of forces you to structure your dependency groups specifically for Hatch—even though they may be used by a variety of tools. I can imagine many other ways to organize these groups; for example, UV lets you compose multiple dependency groups ad-hoc in the CLI, which I would probably arrange very differently than if I were mapping them directly to Hatch environments.