Live data from Hacker News

Switching from Pyenv to Uv

bluesock.org

41–50 of 239 posts

Re: Switching from Pyenv to Uv

#41
I’m enjoying UV a lot as well. If anyone from the Astral team sees this, I’d love to request more functionality or examples around packaging native libraries.

At this point, just thinking about updating CIBuildWheel images triggers PTSD—the GitHub CI pipelines become unbearably slow, even for raw CPython bindings that don’t require LibC or PyBind11. It’s especially frustrating because Python is arguably the ultimate glue language for native libraries. If Astral’s tooling could streamline this part of the workflow, I think we’d see a significant boost in the pace of both development & adoption for native and hardware-accelerated tools.

Re: Switching from Pyenv to Uv

#42
post #33
post #13

15 year Python dev who usually adopts tooling slowly. Just do it, uv's absolutely worth it. I also use mise with it, which is a great combination and gives you automatic venv activation among other things. See, among other mise docs related to Python, https://mise.jdx.dev/mise-cookbook/python.html See also a Python project template I maintain built on mise + uv: https://github.com/level12/coppy

ideally mise could be replaced entirely by uv or at least just be a thin wrapper around uv (in some ways that's already the case), but given this article requires the use of the custom uv-python-symlink utility it seems uv isn't quite there yet

Mise does way more than uv, it's a much larger scope than just Python tooling.

I think the current status quo, that of mise utilizing uv for it's Python integration support, makes sense and I don't see that changing.

Also, FWIW, mise has other methods for Python integration support, e.g. pyenv, virtualenv, etc.

Edit:

Ha... Didn't realize who I was replying to. Don't need me to tell you anything about mise. I apparently misinterpreted your comment.

Re: Switching from Pyenv to Uv

#43

Is there a guide for how to use uv if you're a JS dev coming from pnpm? I just want to create a monorepo with python that's purely for making libraries (no server / apps). And is it normal to have a venv for each library package you're building in a uv monorepo?

If the libraries are meant to be used together, you can get away with one venv. If they should be decoupled, then one venv per lib is better. There is not much to know: - uv python install if you want a particular version of python to be installed - uv init --vcs none [--python ] in each directory to initialize the python project - uv add [--dev] to add libraries to your venv - uv run when you want to run a command i…

uv sync if you clone a github repo

Re: Switching from Pyenv to Uv

#44
post #36

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…

The install speed alone makes it worthwhile for me. It went from minutes to seconds.

I was working on a Raspberry Pi at a hackathon, and pip install was eating several minutes at a time.

Tried uv for the first time and it was down to seconds.

Re: Switching from Pyenv to Uv

#46
post #27

I wasn’t able to figure how to make a uv installed python version a global when “python” is called, at least in the current shell, as I need it in CI.

That feature's in preview now. You can run it like: uv python install --preview --default 3.13 and then you get Python 3.13 whenever you run `python` outside of an environment that declares something else.

This is great news. I had hacked together some bash and fish scripts to mostly do this but they still had some rough edges. I missed that uv now had this ready for preview

Re: Switching from Pyenv to Uv

#48
post #42
post #33

Earlier quoted context omitted.

ideally mise could be replaced entirely by uv or at least just be a thin wrapper around uv (in some ways that's already the case), but given this article requires the use of the custom uv-python-symlink utility it seems uv isn't quite there yet

Mise does way more than uv, it's a much larger scope than just Python tooling. I think the current status quo, that of mise utilizing uv for it's Python integration support, makes sense and I don't see that changing. Also, FWIW, mise has other methods for Python integration support, e.g. pyenv, virtualenv, etc. Edit: Ha... Didn't realize who I was replying to. Don't need me to tell you anything about mise. I apparent…

the reality that I'm sure you've heard me say many times is that I'm just not a python dev and astral is likely always going to build a better solution around python than I ever could. They've just focused a lot more on the package manager side of things than the runtime/venv management side so far but I suspect that will change—and given astral's velocity I doubt we'll be waiting long

and btw mise's venv support isn't going anywhere probably ever, but I do hope that at some point we could either let uv do the heavy lifting internally or point users to uv as a better solution

Re: Switching from Pyenv to Uv

#49
UV is such a big improvement that it moves Python from my "would use again if I had to, but would really not look forward to it" pile to my "happy to use this as needed" pile. Without disparaging the hard work by many that came before, UV shows just how much previous tools left unsolved.

Re: Switching from Pyenv to Uv

#50

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.

Ruff is already integrated into uv and Astral are working on type checker.
Post reply on HN