johnthagen/python-blueprint

Port from Poetry to uv

Closed this issue · 5 comments

johnthagen commented

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)
  • 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 nox
  • uv, 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.
  • 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.lock support in Nox

Nice to Have

uv

Nox

PyCharm

Dependabot

Migration Guide

Other changes

python-blueprint/.dockerignore

Line 8 in 35be74f

!poetry.lock

johnthagen commented

uv 0.5.0 had a lot of breaking changes

So it's probably still prudent to continue to let it settle in while it goes through it's rapid early development.

drmikehenry commented

There's nothing wrong with waiting for some dust to settle, but the items marked "Breaking changes" in the 0.5.0 release notes don't seem very destabilizing to me. Because they potentially "could break some workflows", they've been gathered into a new 0.x.0 release, but these changes "have been marked as breaking out of an abundance of caution. We expect most users to be able to upgrade without making changes."

Also interesting is this issue and associated pull request that's in review:

When the pull request lands, uv will be marked with the classifier "Development Status :: 5 - Production/Stable".

So Astral may soon be considering uv to be stable.

  • 👍2
benomahony commented

Looks like this has landed!

johnthagen commented

Dependabot support looks to have landed in a broken state, so will want the dust to settle on that

  • 👍1
johnthagen commented

For those needing to migrate and are looking for a tool, see