pypa
[request] Support for `[dependency-groups]`
Please, implement the recently standardized [dependency-groups] table as defined in PEP 735
Related issue: #754
i don't think that spamming the issue list with quasi redundant items is helpful in any regard.
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.
@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.
@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.
The example breaks down if you remove pytest; now you have a dependency group that only exists so you can reference what you want.
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.
OK, so how about this:
Internal hatch envs (hatch-lint, hatch-test, …) and maybe also the default env work as I described. That way, one can e.g. control the dependencies of hatch test without any tool.hatch configuration.
Other envs still need the [tool.hatch.envs.$name] table to exist (even if empty) for them to exist (appear in hatch.env.lint)
That would mean
[dependency-groups]
hatch-test = ["foo"]
means that hatch test installs the foo package into the envs it creates
[dependency-groups]
doc = ["sphinx"]
would mean nothing for hatch
[dependency-groups]
doc = ["sphinx"]
[tool.hatch.envs.doc]
would e.g. mean that one could do hatch run doc:sphinx-build
[dependency-groups]
doc = ["sphinx"]
[tool.hatch.envs.doc]
dependency-groups = []
would mean that the doc env exists but doesn’t inherit its dependencies from the doc dependency group.