What do you think about uv?

[pawamoy]

https://github.com/astral-sh/uv

Have you tried it 🙂? Do you think it could be integrated within PDM to speed it up?

[nick-robo]

It's really fast

[deronnax]

very interesting takes from some python core developers: https://simonwillison.net/2024/Sep/8/uv-under-discussion-on-mastodon/.
My take: it's not python, so I would like to avoid using it. Renovate bot is doing our lock and update, so speed isn't too much of a problem.

[pawamoy]

You're probably using other libs/tools that are not pure-Python, no 😄?

[deronnax]

Besides Git and PyCharm, no

[pawamoy]

Well congrats! It's probably quite hard to avoid any non pure Python dependency these days 🙂

[deronnax]

hmmm sorry, I lacked precision: the tools are pure python, the libraries are not (psycopg, for a start). I don't care that the dependencies aren't pure python, mostly python is fine. But not python is not.

[canol]

They make it a big deal that it is fast but I never thought speed is a problem with existing package management solutions. The problem with existing package managers is usually missing features or not supporting some use cases.

[deronnax]

I don't think I have seen an use case PDM doesn't support. But yes, it's pretty slow. Poetry is blazing fast (for python), what is preventing its dominance to me now is that it doesn't support PEP621, but it's on the way. When it does, I don't see the point of uv anymore. uv will be 10 times faster than something that is already fast enough, and it's not python.
One problem that uv solves though and even die-hard python concur: it solves the python bootstrapping problem (chicken-egg). uv is a single drop in binary that you can drop and it will get you a working python and packages. In that it has great value.
Once you are there, just use your regular pure python environment and tools, as usual.

[pawamoy]

PDM was faster than Poetry at some point 😄 Then Poetry got faster again 🙂

The current maintainers of Poetry seem to be doing a good job on it. Mainly, bringing support for PEP 621. But note that it took 4 years! Whereas Astral has added support for PEP 735 in just a few days, for example.

There are other issues with Poetry still. Take for example their use of ^ by default when adding dependencies, or even for specifying the required Python version. This is causing issues in the ecosystem (and ^ is not even standard). Well, even with their PEP 621 support, they still add upper bounds to dependencies by default!

dependencies = [
    "loguru (>=0.7.2,<0.8.0)",
]

uv will be 10 times faster than something that is already fast enough

It's really more than 10 times. Personally, I very often find myself in need for reinstalling dependencies, or recreating venvs, so uv is an incredible time saver, both locally and in CI. That means it's also a money-saver for some companies 😄

% time (poetry lock; poetry install)
Resolving dependencies... (0.1s)
Installing dependencies from lock file

No dependencies to install or update

Installing the current project: griffe (100)
( poetry lock; poetry install; )  1.36s user 0.14s system 94% cpu 1.596 total

% time (uv lock; uv sync)           
Resolved 117 packages in 1ms
Resolved 117 packages in 1ms
Uninstalled 1 package in 0.14ms
Installed 1 package in 2ms
 - griffe==100 (from file:///media/data/dev/griffe)
 + griffe==1.5.2.dev4+g1c419dc0.d20241114 (from file:///media/data/dev/griffe)
( uv lock; uv sync; )  0.03s user 0.03s system 100% cpu 0.056 total

% python -c "print(1.596 / 0.056)"
28.5

uv just got 28x faster than Poetry (warm cache for both). Expect a higher speed up with cold cache / no cache. Yes a part of Poetry's slowness compared to uv is starting the Python interpreter. That counts towards the final result and user experience IMO.

Yes, one second is fast. But in my case, repeat that 6 or 7 times per project (default venv, + one venv per supported Python version), for each project, multiple times every day, and you really notice the difference.