How do uv and Poetry compare?
Poetry and uv both manage Python projects through pyproject.toml, create lockfiles, and handle virtual environments. The handbook recommends uv for new projects; Poetry remains a reasonable choice for an established workflow or required plugins.
Compare the 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
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 compare uv with pip, not Poetry.
Share standard metadata across tools
Both tools support PEP 621 project metadata in [project], with dependencies written as PEP 508 requirement strings. Poetry also reads legacy [tool.poetry] metadata. Prefer the standard tables for new configuration, as explained in Poetry’s support for packaging standards.
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 can build a legacy Poetry package through poetry-core without converting its metadata first.
Keep each tool’s lockfile
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 generates a new lockfile rather than renaming the old one.
Run commands in the project environment
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
Poetry’s python commands 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
Both tools read PEP 735 dependency groups in [dependency-groups]. Poetry also accepts [tool.poetry.group.<name>.dependencies]. Use [project.optional-dependencies] for extras shipped to package users.
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
Poetry has poetry build and poetry publish; uv has uv build and uv publish. For publishing to PyPI from CI, use trusted publishing. The publishing tutorial walks through the uv workflow.
Check plugin requirements before migrating
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
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.