Live data from Hacker News

Switching from Pyenv to Uv

bluesock.org

141–150 of 239 posts

Re: Switching from Pyenv to Uv

#141

I dabble with python occasionally and I'm always fighting with tools and tool combinations that don't really combine well. The last time I settled on using conda to get some isolation of python versions and then pipenv for getting some sane package management with a lock file. Not pretty but it kind of worked. Except I had a hard time convincing vs code and pycharm of the correct environment with that combination (co…

Do. I was sceptical at first - exactly because of the points you make: I mostly do ML, so for getting PyTorch and Cuda etc. to play nice conda was basically my go-to.

We use poetry at work, but getting it to play nice with PyTorch is always a bit of an art. I tried to get into Pixi, but have been a little annoyed as it seems to have inherited conda's issues when mixing conda and PyPi.

uv so far has been relatively smooth sailing, and they even have an entire section on using it with PyTorch: https://docs.astral.sh/uv/guides/integration/pytorch/

Re: Switching from Pyenv to Uv

#142

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…

uv belongs to a startup. They will surely introduce some wacky monetisation scheme sooner or later.

I wouldn't get too used to it.

Re: Switching from Pyenv to Uv

#143
I recently switched our Python projects to uv and it love it. It just does everything and is really fast (this just cannot be underestimated in what it means for your workflow).

I've tried almost every Python packaging solution under the sun in the past 15 years but they all had their problems. Finally I just stuck with pip/pip-tools and plain venv's but strung together with a complicated Makefile to optimize the entire workflow for iteration speed (rebuilding .txt files when .in requirements changes, rebuilding venv if requirements change, etc). I've been able to reduce it to basically one Make target calling uv to do it all.

Re: Switching from Pyenv to Uv

#144
post #121
post #83

Earlier quoted context omitted.

Strong agree. The respectful act of other package managers would be consider themselves deprecated and point to uv instead.

The risk is obviously uv losing funding. I kinda hope the PSF has thought about this and has a contingency plan for uv winning and dying/becoming enshittified soon after.

If they never made any plan about how modules are installed and there is no official way… i doubt they made a plan about uv.

Re: Switching from Pyenv to Uv

#145
post #90

Earlier quoted context omitted.

Could you give some detail on things you've found that still don't work as described?

I could use more guidance on migration for setups where development and testing is using Docker. I figured things out eventually. The issue here is lack of good tutorials that cover cases other than a happy path.

> I figured things out eventually. The issue here is lack of good tutorials that cover cases other than a happy path.

I'd like to encourage you to blog about it, then.

Re: Switching from Pyenv to Uv

#146

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…

I totally disagree. Having a single vendor with that much power is a bad idea. If the PSF were able to focus on tooling rather than their current focus, they would be great stewards of this sort of thing. Sadly I doubt that will happen, in which case I think many options is the best approach.

Re: Switching from Pyenv to Uv

#147
post #119
post #40

Earlier quoted context omitted.

Agree. I mostly do front end in my day job, and despite JavaScript being a bit of a mess lang, dealing with npm is way better than juggling anaconda, miniforge, Poetry, pip, venv, etc depending on the project. UV is such a smooth UX that it makes you wonder how something like it wasn’t part of Python from the start.

+1 …but we did have to wait for cargo, npm (I include yarn and pnpm here) and maybe golang to blaze the ‘this is how it’s done’ trail. Obvious in hindsight.

Ruby's bundler had already invented the correct model many years ago. It only took time for others to accept that.

Re: Switching from Pyenv to Uv

#148

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'm pretty much with you and still trying to figure out why I want to switch away from pyenv+poetry.

I get that uv does both, but I'm very happy with pyenv+poetry combo.

Old baggage, but I came from the rvm world which attempted to do exactly what uv does, but rvm was an absolute mess in 2013. rbenv+bundler solved so many problems for me and the experience was so bad that when I saw uv my gut reaction was to say "never again".

But this thread has so many praises for it so one day maybe i'll give it a try.

Re: Switching from Pyenv to Uv

#149
post #40

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…

Agree. I mostly do front end in my day job, and despite JavaScript being a bit of a mess lang, dealing with npm is way better than juggling anaconda, miniforge, Poetry, pip, venv, etc depending on the project. UV is such a smooth UX that it makes you wonder how something like it wasn’t part of Python from the start.

You mean off the job you have to juggle all those tools? On the job that would be kind of crazy, to allow every project its own tool chain.

Re: Switching from Pyenv to Uv

#150

I've stuck with simple tools for all these years: pip, pip-tools, virtualenvwrapper etc. I've tried other stuff like poetry and it's always seemed like hard work. I'm glad I waited for uv. The one thing I wish it supported is having venvs outside of project directories. It's so much nicer to have them all in one place (like ~/.venvs or something) which you can ignore for backups etc. That's the only thing I miss, tho…

I'm also only missing virtualenvwrapper-like support for central named venvs in uv.

I'm too used to type virtualenvwrapper's `workon` and `mkvirtualenv` commands, so I've written some lightweight replacement scripts of virtualenvwrapper when using uv. Supports tab completion and implements only the core functionality of virtualenvwrapper:

https://github.com/sitic/uv-virtualenvwrapper

Post reply on HN