Live data from Hacker News

Switching from Pyenv to Uv

bluesock.org

61–70 of 239 posts

Re: Switching from Pyenv to Uv

#62

[flagged]

You're being downvoted (for snark presumably) but you have a point. During my tenures as a Python developer I've had to deal with pip, pipx, venv, pipenv, setuptools, conda, and poetry. I'd not heard of pyenv or uv until this thread (or maybe I've touched pyenv and got it confused with one of the 7 other tools I mentioned) and I'm sure there are other dependency/environment management tools floating around that I mis…

The reason there have been so many is because the standard included tools (pip, venv) are not great. And others could still use improvements.

Venv and setup tools aren't really package managers. Pipx is only meant for installing Dev tools per user (in isolated Venvs).

pyenv does something a bit different from those tools you listed(maybe it'd part of cones I haven't tried it). Its not a dependency manager its a python version manager like nvm (node version manager). It helps you manage downloading and compiling python from source and it let's you specify python version in a .python-version file and provides a shim to find the right python for a project(compiling it if its not already available).

I tried pipenv and despite being hyped for it, it had a lot of issues. Then I tried poetry which seemed much better but was still sort of slow and got stuck updating lock files sometimes.

I haven't even tried pdm. Or various conda package managers since its mainly used by scientists with lots of binary dependency needs.

Then ~~uv~~ rye came along and seemed to fix things. It replaced pip+pip tools/pipenv/poetry. Also replaced pipx(install python tools in isolated venvs then add it to users ./local/bin). Also replaced pyenv but instead of compiling python which takes a while and can be troublesome it downloads portable builds https://astral.sh/blog/python-build-standalone (which do have some downsides/compatibility issues but are usually better then compiling python). It was also written in rust so avoided circular venv issues that sometimes come with installing python packages since it had a self contained binary(plus some shims).

Then UV came along, the projects merged and most development is happening in uv. Despite the rye-> switch most things are pretty similar and I feel a lot of excitement towards it. The one big difference is there's no shims to automatically call the right python for a project from UV. Instead you need to run uv run script.py

Astral the guys behind UV took over the independent python builds and have also built the most popular python formater/linter these days - ruff (also written in rust, also fast they're also looking into adding a better type checker for python type hints).

I'd reccomend trying it for your next project I think it could become the defacto packaging/version tool for python

Re: Switching from Pyenv to Uv

#63
If uv figures out a way to capture the scientific community by adding support for conda-forge that'll be the killshot for other similar projects, imo. Pixi is too half-baked currently and suffers from some questionable design decisions.

Re: Switching from Pyenv to Uv

#65

I highly, highly recommend uv. It solves & installs dependencies incredibly fast, and the CLI is very intuitive once you've memorized a couple commands. It handles monorepos well with the "workspaces" concept, it can replace pipx with "uv tool install," handle building & publishing, and the docker image is great, you just add a FROM line to the top and copy the bin from /uv. I've used 'em all, pip + virtualenv, conda…

That scripting trick is awesome! One of the really nice things about Elixir and its dependency manager is that you can just write Mix.install(…) in your script and it’ll fetch those dependencies for you, with the same caching you mentioned too.

Does uv work with Jupyter notebooks too? When I used it a while ago dependencies were really annoying compared to Livebook with that Mix.install support.

Re: Switching from Pyenv to Uv

#66

The functionalities of three tooling projects, namely uv, ruff (linter), and pyright (type checker) need to merge and become mandatory for new Python projects. Together they will bring some limited sanity to Python.

What benefit does merging provide?

In an ideal world they shouldn't have to, but in the real world, it makes it easier for enterprises to adopt without friction. Adopting three tools is a threefold bigger challenge in enterprises, but thinking about it as a single tool makes it more amenable to enterprise adoption where it's needed the most. The merging I suggest is only logical, more like a bundling.

Re: Switching from Pyenv to Uv

#67

I am pretty happy with poetry for near future. I prefer using python interpreters installed by linux package manager. In cloud I use python docker. Poetry recently added option to install python too if I changed my mind. I have already setup CI/CD pipelines for programs and python libraries. Using uv would probably save some time on dependency updates but it would require changing my workflow and CI/CD. I do not thin…

> I prefer using python interpreters installed by linux package manager.

uv will defer to any python it finds in PATH as long as it satisfies your version requirements (if any):

https://docs.astral.sh/uv/concepts/python-versions/

It also respects any virtual environment you've already created, so you can also do something like this:

   /usr/bin/python3 -m venv .venv
   .venv/bin/pip install uv
   .venv/bin/uv install -r requirements.txt # or
   .venv/bin/uv run script ...
It's a very flexible and well thought out tool and somehow it manages to do what I think it ought to do. I rarely need to go to its documentation.

> Using uv would probably save some time on dependency updates but it would require changing my workflow and CI/CD.

I found it very straightforward to switch to uv. It accommodates most existing workflows.

Re: Switching from Pyenv to Uv

#69

Earlier quoted context omitted.

What benefit does merging provide?

In an ideal world they shouldn't have to, but in the real world, it makes it easier for enterprises to adopt without friction. Adopting three tools is a threefold bigger challenge in enterprises, but thinking about it as a single tool makes it more amenable to enterprise adoption where it's needed the most. The merging I suggest is only logical, more like a bundling.

Hmmm, I've never seen that and I feel like I work with some pretty locked down companies.

Re: Switching from Pyenv to Uv

#70

Earlier quoted context omitted.

uv sync if you clone a github repo

uv run in the freshly cloned repo will create the venv and install all deps automatically. You can even use --extra and --group with uv run like with uv sync. But in a monorepo, those are rare to use.

Thanks for the info.

I looked at the group documentation, but it's not clear to me why I would want to use it, or where I would use it:

https://docs.astral.sh/uv/concepts/projects/layout/#default-...

(I'm a JS dev who has to write a set of python packages in a monorepo.)

Post reply on HN