Port from Poetry to uv #238
Description
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 Poetryand is a desirable feature in and of itself (i.e. rustup for Python) - 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
uvsupports 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 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.
uvdoes not respectrequires-pythonupper bounds, which is very nice in practice- Poetry still enforces this upper bound: Remove upper bound checking on Python version python-poetry/poetry#10136
uvcan 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 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.
- Dependency groups PEP 735: This is a feature that Poetry has and uv only currently has support for a single "dev" group. It is nice to be able to break up dependencies into logical groups and provide support for installing them independently.
- Support for PEP 735: Dependency Groups in
pyproject.tomlastral-sh/uv#8090 - Note, Poetry does not support this either, but has it's own concept of dependency groups: Support PEP 735 – Dependency Groups in pyproject.toml python-poetry/poetry#9751
- Support for PEP 735: Dependency Groups in
- PEP 751 standardized lockfiles: Like Poetry, uv has it's own custom lockfile format. There is on going discussions about creating a standardized lockfile format. If approved, it may be nice to wait until uv supports this, so that users do not have to migrate lockfiles twice (once to uv's custom format, and again to the standardized format).
-
uv.locksupport in Nox
Nice to Have
uv
- uv having it's own build backend
- Add a uv build backend astral-sh/uv#3957
- Poetry provides it's own build backend, and it's nice to not have to track two different projects to form the entire pipeline of build and packaging. In uv's case, currently one would have to track uv and hatchling.
- uv updating top level dependencies in
pyproject.toml - uv supporting private projects
- Private Projects astral-sh/uv#8214
- Note, Poetry does not support this either: Implement private projects python-poetry/poetry#1537
-
uv checksimilar topoetry check -
uvequivalent to Poetrypackage-mode -
uv syncinstall all dependancy groups by default -
uv syncdefault to--locked
Nox
- Nox supports installing dependency groups
- Enable reading dependency specifiers from PEP 621
pyproject.tomlwntrblm/nox#845 - Note:
nox-poetrydoes not have this either
- Enable reading dependency specifiers from PEP 621
PyCharm
- Native PyCharm support: PyCharm already automatically supports the
.venvvirtual environments created, but it would be even better if it supported introspectinguv.lockand provided features similar to its native Poetry integration
Dependabot
- Dependabot support for
uv.lock
Migration Guide
poetry sync->uv sync- Lockfile freshness:
uv lock --check - Remove
tool.poetry.dependencies.pythonupper 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-versionfile- Add
[tool.uv.default-groups]asuvdoes 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
python-blueprint/.dockerignore
Line 8 in 35be74f