# How do uv and Poetry compare?

[Poetry](https://pydevtools.com/handbook/reference/poetry.md) and [uv](https://pydevtools.com/handbook/reference/uv.md) both manage Python projects through [pyproject.toml](https://pydevtools.com/handbook/reference/pyproject.toml.md), create [lockfiles](https://pydevtools.com/handbook/explanation/what-is-a-lock-file.md), and handle [virtual environments](https://pydevtools.com/handbook/explanation/what-is-a-virtual-environment.md). The handbook recommends uv for new projects; Poetry remains a reasonable choice for an established workflow or required plugins.

## Compare the scope {#scope}

Both tools handle dependency management, virtual environments, building, and publishing. Poetry also has experimental Python interpreter management. uv, built by Astral, now part of OpenAI, adds isolated CLI tool execution through `uvx` and a pip-compatible installation interface.

## Measure installation time on your project {#speed}

The handbook recommends uv for faster dependency resolution and installation. Measure your own project with the same dependencies and cache conditions before estimating CI savings; the [benchmarks in the complete guide](https://pydevtools.com/handbook/explanation/uv-complete-guide.md#how-fast-is-uv) compare uv with pip, not Poetry.

## Share standard metadata across tools {#standards-alignment}

Both tools support [PEP 621 project metadata](https://pydevtools.com/handbook/explanation/what-is-pep-621-compatibility.md) in `[project]`, with dependencies written as [PEP 508 requirement strings](https://pydevtools.com/handbook/explanation/what-is-pep-508.md). Poetry also reads legacy `[tool.poetry]` metadata. Prefer the standard tables for new configuration, as explained in [Poetry's support for packaging standards](https://pydevtools.com/handbook/explanation/poetry-python-dependency-management.md).

Standard metadata transfers between tools; tool-specific configuration does not. Poetry sources, plugins, and package discovery need review during migration, as do uv-specific sources and indexes when leaving uv. A [PEP 517 build frontend](https://pydevtools.com/handbook/explanation/what-is-a-build-frontend.md) can build a legacy Poetry package through `poetry-core` without converting its metadata first.

## Keep each tool's lockfile {#lockfiles}

Poetry writes `poetry.lock`; uv writes `uv.lock`. Both record resolved versions and artifact hashes and support dependencies that vary by platform. Each tool uses its own format, so [migration to uv](https://pydevtools.com/handbook/how-to/how-to-migrate-from-poetry-to-uv.md) generates a new lockfile rather than renaming the old one.

## Run commands in the project environment {#virtual-environment-management}

Poetry normally creates virtual environments in a centralized cache directory and can use an in-project `.venv`. uv creates `.venv` in the project by default. Both can run commands without shell activation: Poetry uses `poetry run`, while `uv run` executes the command inside the project's virtual environment, ensuring all dependencies are installed first.

For manual activation, `poetry env activate` prints a shell command that you then execute. It does not activate the calling shell itself. `poetry shell` requires the separate `poetry-plugin-shell` plugin.

## Manage Python interpreters {#python-version-management}

Poetry's [`python` commands](https://python-poetry.org/docs/cli/#python) install, list, and remove managed Python interpreters. Poetry labels this feature experimental; using an existing interpreter with `poetry env use` remains an option.

uv installs and manages Python versions directly. A `.python-version` file selects the project's interpreter, and `uv run` uses it automatically.

## Separate development dependencies from extras {#dependency-groups}

Both tools read [PEP 735 dependency groups](https://pydevtools.com/handbook/explanation/what-is-pep-735.md) in `[dependency-groups]`. Poetry also accepts `[tool.poetry.group.<name>.dependencies]`. Use `[project.optional-dependencies]` for [extras shipped to package users](https://pydevtools.com/handbook/explanation/what-are-optional-dependencies-and-dependency-groups.md).

Poetry installs all non-optional groups by default; uv defaults to the `dev` group. Check the generated default-group settings when migrating so the installed development tools stay the same.

## Build and publish packages {#publishing}

Poetry has `poetry build` and `poetry publish`; uv has `uv build` and `uv publish`. For publishing to PyPI from CI, use [trusted publishing](https://docs.pypi.org/trusted-publishers/). The [publishing tutorial](https://pydevtools.com/handbook/tutorial/publishing-your-first-python-package-to-pypi.md) walks through the uv workflow.

## Check plugin requirements before migrating {#plugin-ecosystem}

Poetry supports plugins, including `poetry-plugin-export` for `poetry export`. uv has no plugin system. Check whether uv or a standalone build backend covers each required plugin's behavior before switching.

## Choose for your project's needs {#when-to-choose-each}

Use uv for new projects that need integrated Python, dependency, and CLI tool management. Keep Poetry when its workflow works for the team or migration would disrupt required plugins. When ready to switch, follow [How to migrate from Poetry to uv](https://pydevtools.com/handbook/how-to/how-to-migrate-from-poetry-to-uv.md).