Live data from Hacker News

Switching from Pyenv to Uv

bluesock.org

91–100 of 239 posts

Re: Switching from Pyenv to Uv

#91

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.

i believe there is a type checker branch on ruff git

Re: Switching from Pyenv to Uv

#93

Because pyenv compiles from source, it's optimized for your own platform. In practice, are these performance differences noticeable?

For what it's worth, I didn't notice a difference between my distro-provided Python 3.12 and the one I built from source - and enabling profile-guided optimization made only a slight difference. I haven't tested with the precompiled versions uv uses, so they could be slower for some reason, but I doubt it. On the other hand, my hardware is rather old, so maybe newer machines allow for significant optimizations that the system version wouldn't have. But I still kinda doubt it.

If performance is important to you, the ancient advice to profile bottlenecks and implement important parts in C where you can, still applies. Or you can try other implementation like PyPy.

Re: Switching from Pyenv to Uv

#96

[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…

> 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)

I must have seen at least a dozen threads here about uv since joining half a year ago. But maybe that's because I actively look for Python discussion (and I'm probably just generally more active here).

I wish I'd paid more attention a few years ago and thought about the packaging problem more intensely - in an alternate universe I might have released Paper before uv came out, but I didn't even really start considering these issues until mid-2023 (and of course I've had plenty of other things to distract me since then).

For what it's worth, my general thesis is that most of the problems really boil down to Pip being what it is, and a lot of the rest boil down to Setuptools being what it is.

Re: Switching from Pyenv to Uv

#97
post #62

Earlier quoted context omitted.

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 pytho…

`venv` is fine. The work of just creating the virtual environment is hardly anything, and `venv` really can't screw it up. If you create environments `--without-pip`, it's actually faster than `virtualenv` and `uv venv` in my testing (because those are fundamentally doing the same thing with a little extra window dressing). What slows it down is bootstrapping Pip into the new environment, via the standard library `ensurepip`, which requires running zipped un-bytecode-compiled code from a bundled wheel.

(As it happens, this is the exact topic of the blog post I'm currently in the middle of writing.)

Pip is indeed not great (understatement - there are many other things about it that I have picked on or will pick on in this series).

>Venv and setup tools aren't really package managers.

Setuptools nowadays is a build backend. Long ago (when expectations were much lower), Pip had Setuptools as a dependency, and the combination was about as close to a "package manager" as anyone really cared for. But Pip today really can't be called anything like a "package manager" either - it only installs the packages, and resolves dependencies. It records some basic information about the dependency graph of the things it installed - in the sense that it preserves such information from the wheels it installs - but it doesn't really do any processing of that information. If you ask it to remove packages it's (last I checked) not very smart about that. It doesn't help you figure out what packages you need, and it doesn't help you maintain your `pyproject.toml` file.

And, of course, it doesn't create or keep track of virtual environments for you. (Pipx does the latter, wrapping Pip and `venv`, but it only installs "application" packages that define an entry point.)

Poetry and PDM are the only things listed that really belong to the same category as uv. They're not only package managers, but complete workflow tools. (Conda is a package manager, for languages other than Python as well, but it's not meant to take over your entire Python workflow in the same way.) They even wrap themselves around the process of uploading to PyPI (which seems really excessive to me; seriously, `twine` is fine too.)

Re: Switching from Pyenv to Uv

#98

Uv really fixes Python. It takes it from "oh god I have to fight Python again" to "wow it was actually fast and easy". I think all the other projects (pyenv, poetry, pip, etc.) should voluntarily retire for the good of Python. If everyone moved to Uv right now, Python would be in a far better place. I'm serious. (It's not going to happen though because the Python community has no taste.) The only very minor issue I'v…

Which companies run heavily (either solely or huge parts) run on Python? They should take initiative and start blogging.

Re: Switching from Pyenv to Uv

#99

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.

which subfield of scientific community uses that? and for what purpose, if you could summarize

Re: Switching from Pyenv to Uv

#100

Because pyenv compiles from source, it's optimized for your own platform. In practice, are these performance differences noticeable?

Hi! I work on the Python distributions uv uses. Performance is really important to us and we're on the bleeding edge of performant Python builds. Our distributions use profile guided optimization (PGO) as well as post-link optimizations (BOLT). From my understanding, these are not enabled by pyenv by default because they significantly increase build times. It's possible there are some platform-specific build benefits, but I'd be surprised if it was significant.

I can set up some benchmarks comparing to pyenv on a couple common platforms – lately I've just been focused on benchmarking changes to CPython itself.

Post reply on HN