articles/2024/python-poetry-vs-uv/

[giscus[bot]]

articles/2024/python-poetry-vs-uv/

Comparing two Python package managers: Poetry and new kid on the block uv.

https://www.loopwerk.io/articles/2024/python-poetry-vs-uv/

[dusktreader]

I appreciate the article, and I share your sentiment. I don't feel that uv is quite ready to replace poetry in my workflows yet.

However, something caught my attention when you were suggesting that you can replace pyenv with uv. I've managed to do this, and there's a step that's very useful for getting poetry to use a python version installed via uv. I do not set a local version of python to create the .python-version file.

Instead, I initialize the virtual environment that poetry uses with a python version installed by uv. You can do that with one command using:

poetry env use $(uv python find 3.12)

You can, of course change the python version to whichever you prefer as long as it's installed on your system and uv can detect it.

After that, it's simply a matter of running poetry install to install your project. I've found this workflow is preferable to creating the .python-version file and committing it to source control.

Cheers!

[kfchou]

Can you think of any reasons to not do this the other way around? i.e., first create a venv with some python version with

uv venv .venv-3.12 --python 3.12

then activate it as usual. Since Poetry will use any existing venv for installation, do poetry install to install your requirements in that environment.

[dusktreader]

When I'm working with poetry, I don't like to work inside of activated virtual environments. Just a personal preference there.

[RafalSkolasinski]

Dependency groups should now be supported astral-sh/uv#5632

[kevinrenskers]

Yup, which is why I’ve switched over :) See the update at the bottom of the article.

[RafalSkolasinski]

Ah I should have read to the end before lurking out for new changes!

[nlhnt]

pyenv isn't slow, it's building the Python distribution from source

uv downloads a prebuilt binary, which means you might not get a working python on certain systems

This might be a niche but uv won't work on some systems unless they're binary compatible with the python distributions available for download through uv - not sure if they build their own binaries or just download them from somewhere.

[kevinrenskers]

pyenv isn't slow, it's building the Python distribution from source

Yeah, which takes a long time. It's slow.

you might not get a working python on certain systems

Which systems? Source?

uv won't work on some systems

Which systems? Source?

[dusktreader]

uv downloads a prebuilt binary, which means you might not get a working python on certain systems

This is true, but it is a pretty small edge-case. It would be nice if uv offered a feature to build a python version from source.

not sure if they build their own binaries or just download them from somewhere

Astral took over the python-build-standalone project which builds across a pretty impressive matrix of systems.

[d-subrahmanyam]

Kevin,

Great article. I'm a newbie to Python and its build managers, I come from a Java background where we use either Maven or Gradle for build management. One of the downsides with either uv or poetry (not sure) is that the env created is local to a project as a result if multiple projects use similar dependencies they end up having the same copy of dependencies downloaded and installed local to their project folders, This makes them lees re-usable and increases the disk consumption especially if your projects are using tensorflow and pytorch which have a dependencies close to a Gig in size.

[kevinrenskers]

That’s a fair point. uv keeps a global cache so packages are downloaded and built only once, but virtual environments still contain their own installed copies of packages. A pnpm-style shared package store with symlinks could reduce disk usage, but Python tooling hasn’t widely adopted that approach yet.