Given the funding and momentum behind uv, it seems inevitable that it will become the most powerful, de facto packaging tool for Python. When it is deemed ready, it should be recommended in place of Poetry.
Benefits
- Bootstrapping: A source of friction with Poetry is that users must first be instructed on how to install Python and pipx before they can install Poetry
- uv can install Python itself,
which is totally outside the scope of Poetry and is a desirable feature in and of itself (i.e. rustup for Python)
- Poetry is adding this feature too
- Speed: uv, being written in Rust and also having a design focus on performance, will likely out perform Poetry on every benchmark
- Single binary: uv is distributed as a single binary meaning that all, among other things, users of uv version X get the exact same code. On the other hand, Poetry does not pin its dependencies so breakages can occur and not all users are guarenteed to have the same third party libraries installed with it
uv supports MUSL natively, so it can install natively on MUSL-based operating systems like Alpine, which is used in some container images
Poetry, on the other hand, depends on packages that may or may not have MUSL-wheels uploaded to PyPI- As of Poetry 2.2.1, Poetry no longer seems to exhibit this problem and all of it dependencies can install into into alpine containers directly
- uv supports running scripts with PEP 723 Inline script metadata, while it does not appear Poetry supports this. pipx would need to be used for this, which further fragments the tools users must understand and keep up to date.
uv does not respect requires-python upper bounds, which is very nice in practice
uv can express required platforms for wheel coverage
uv creates virtual environments so quickly that we can avoid needing to "reuse" them when using noxuv, as a single binary, is faster to install in CI than Poetry which has dozens of transitive Python dependencies
Upstream Requests
uv is still a fast moving project and it may be advantageous to wait to recommend moving to it until a few things have settled.
Nice to Have
uv
Nox
PyCharm
Dependabot
Migration Guide
poetry sync -> uv sync- Lockfile freshness:
uv lock --check
- Remove
tool.poetry.dependencies.python upper bound that is required by Poetry
tool.poetry.group -> [dependency-groups]
poetry update - > uv lock --upgradepoetry update typer -> uv lock --upgrade-package typer[tool.poetry.dependencies.python] -> .python-version file
- Add
[tool.uv.default-groups] as uv does not install all groups by default
- Replace
nox-poetry -> nox
poetry show --tree -> uv treepoetry export -> uv export--only -> --only-group--only main -> --no-default-groups--no-root -> --no-install-projectpoetry build -> uv build--package-mode = "false" -> tool.uv.package = falseVIRTUAL_ENV -> UV_PROJECT_ENVIRONMENT
Other changes
Given the funding and momentum behind uv, it seems inevitable that it will become the most powerful, de facto packaging tool for Python. When it is deemed ready, it should be recommended in place of Poetry.
Benefits
which is totally outside the scope of Poetryand is a desirable feature in and of itself (i.e. rustup for Python)PDMandUVdo python-poetry/poetry#9905uvsupports MUSL natively, so it can install natively on MUSL-based operating systems like Alpine, which is used in some container imagesPoetry, on the other hand, depends on packages that may or may not have MUSL-wheels uploaded to PyPIuvdoes not respectrequires-pythonupper bounds, which is very nice in practiceuvcan express required platforms for wheel coverageuvcreates virtual environments so quickly that we can avoid needing to "reuse" them when usingnoxuv, as a single binary, is faster to install in CI than Poetry which has dozens of transitive Python dependenciesUpstream Requests
uv is still a fast moving project and it may be advantageous to wait to recommend moving to it until a few things have settled.
pyproject.tomlastral-sh/uv#8090uv.locksupport in NoxNice to Have
uvpyproject.tomlpyproject.toml(uv upgrade) astral-sh/uv#6794uv checksimilar topoetry checkuv checkcommand to validatepyproject.tomluvconfiguration astral-sh/uv#9653uvequivalent to Poetrypackage-modeuv syncinstall all dependancy groups by defaultuv syncdefault to--lockeduv syncdefault to--lockedastral-sh/uv#12372Nox
pyproject.tomlwntrblm/nox#845nox-poetrydoes not have this eitherPyCharm
.venvvirtual environments created, but it would be even better if it supported introspectinguv.lockand provided features similar to its native Poetry integrationDependabot
uv.lockuv.lockdependabot/dependabot-core#10478[dependency-groups]inpyproject.tomldependabot/dependabot-core#10847Migration Guide
poetry sync->uv syncuv lock --check--lockedand--frozenas--checkoperations foruv lockastral-sh/uv#9662tool.poetry.dependencies.pythonupper bound that is required by PoetryRequires-Pythonastral-sh/uv#4086tool.poetry.group->[dependency-groups]poetry update- >uv lock --upgradepoetry update typer->uv lock --upgrade-package typer[tool.poetry.dependencies.python]->.python-versionfile[tool.uv.default-groups]asuvdoes not install all groups by defaultnox-poetry->noxpoetry show --tree->uv treepoetry export->uv export--only->--only-group--only main->--no-default-groups--no-root->--no-install-projectpoetry build->uv build--package-mode = "false"->tool.uv.package = falseVIRTUAL_ENV->UV_PROJECT_ENVIRONMENTOther changes
python-blueprint/.dockerignore
Line 8 in 35be74f