Home Poetry logo

Announcing Poetry 2.2.0

Published on September 14, 2025 in Releases with tags 2.x 2.2

The Poetry team is pleased to announce the immediate availability of Poetry 2.2.0.

If you have a previous version of Poetry installed via pipx, getting Poetry 2.2.0 is as easy as:

$ pipx upgrade poetry

If you used the official installer, you can run:

$ poetry self update

Highlights #

Normalizing dependency group names and nesting dependency groups #

By nesting dependency groups, you can include dependencies from one group in another group. This is useful when you want to aggregate dependencies from multiple groups into a single group, e.g.:

[tool.poetry.group.test.dependencies]
pytest = "^8.0.0"

[tool.poetry.group.lint.dependencies]
ruff = "^0.11"

[tool.poetry.group.dev]
include-groups = [
    "test",
    "lint",
]

[tool.poetry.group.dev.dependencies]
tox = "*"

In this example, the dev group includes all dependencies from the test and lint groups.

In order to support nesting groups, Poetry will normalize group names. This has the side effect that it is no more possible to define two groups with names that will result in the same normalized name, e.g. Test and test.

Add support for PEP 735 dependency groups #

Instead of using Poetry’s custom syntax for defining dependency groups, you can now also use PEP 735 syntax.

For example, instead of

[tool.poetry.group.test.dependencies]
pytest = "^6.0.0"
pytest-mock = "*"

you can now also write

[dependency-groups]
test = [
    "pytest (>=6.0.0,<7.0.0)",
    "pytest-mock",
]

You can also nest dependency groups via include-group:

[dependency-groups]
test = [
    "pytest (>=8.0.0,<9.0.0)",
]
lint = [
    "ruff (>=0.11.0,<0.12.0)",
]
dev = [
    { include-group = "test" },
    { include-group = "lint" },
    "tox",
]
Note
As with project.dependencies and tool.poetry.dependencies, you can also add additional information about a dependency of a group in the Poetry specific section even when using PEP 735 syntax. However, be aware that you cannot add additional dependencies in the Poetry specific section when using PEP 735 syntax; you can only add additional information to dependencies.

Add support for PEP 639 license clarity #

With PEP 639, table values for the project.license as well as license classifiers are deprecated. project.license should be a string representing a valid SPDX expression. License files can be specified in the project.license-files table.

Example:

[project]
# ...
license = "MIT"
license-files = [
    "*-LICENSE",
    "CONTRIBUTORS",
    "MY-SPECIAL-LICENSE-DIR/**/*"
]

Further, license files are no longer placed at the top level of the dist-info directory. Instead, they will be located in a licenses subdirectory.

Note
If you do not specify license files explicitly, Poetry will include common license file names by default as before.

Upcoming Changes #

Defaulting to setuptools instead of poetry-core if no build system is defined #

Per PEP 517, a build tool should fall back to setuptools if no build system is defined in the [build-system] section of pyproject.toml. However, to avoid immediate disruption, Poetry will currently issue a warning in such cases and continue using the built-in poetry-core backend by default. This behavior will change in a future minor release so that Poetry will default to setuptools if no [build-system] section is defined.

Changelog #

Added #

Changed #

Fixed #

poetry-core (2.2.0) #