Skip to content

Does Poetry Support Python Standards for Dependency Management?

by Tim Hopper · Markdown
Packaging

Poetry supports PEP 621 project metadata and PEP 735 dependency groups. Use these standard tables for metadata and dependencies; keep Poetry-specific settings under [tool.poetry].

Declare metadata and dependencies in standard tables

In pyproject.toml, put runtime dependencies in [project] and development tools in [dependency-groups]:

[project]
name = "my-package"
version = "1.0.0"
description = "A short description."
requires-python = ">=3.11"
dependencies = [
    "requests>=2.28",
    "httpx>=0.24",
]

[dependency-groups]
dev = ["pytest>=8.0"]

The dependencies array in [project] uses PEP 508 dependency specifiers, such as requests>=2.28. Poetry’s caret syntax (requests = "^2.28") belongs in [tool.poetry.dependencies].

Reserve [project.optional-dependencies] for extras that users install to enable optional features. Development groups stay out of published package metadata, as explained in Optional dependencies and dependency groups.

Keep Poetry-specific settings under [tool.poetry]

These settings remain Poetry-specific:

  • Package discovery: packages = [{include = "..."}] controls which Python packages the build includes and excludes.
  • Source configuration: [[tool.poetry.source]] points to private registries.
  • Minimum Poetry version: requires-poetry = ">=2.0" sets the minimum Poetry version a project requires.
  • Plugin requirements: [tool.poetry.requires-plugins] declares Poetry plugins the project depends on.

A project can use both tables at once: standard metadata in [project], Poetry-specific options in [tool.poetry].

Build with poetry-core through a standard frontend

The metadata format and the build backend are separate choices. A PEP 517 build frontend, such as uv or pip, installs the backend declared in [build-system] into an isolated build environment by default.

For a Poetry package, declare the standalone poetry-core backend:

[build-system]
requires = ["poetry-core>=2.0"]
build-backend = "poetry.core.masonry.api"

With this configuration, uv build and pip install . work without the Poetry CLI, including when metadata lives in legacy [tool.poetry] tables. The backend interprets those tables; the frontend does not need to understand them.

Standard metadata makes dependencies readable across tools, but Poetry-specific sources, plugins, and package discovery still need review when migrating from Poetry to uv.

Last updated on