Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A year of uv: pros, cons, and should you migrate

bitecode.dev

Post reply on HN
Print view View original

141–150 of 401 posts

Re: A year of uv: pros, cons, and should you migrate

#141

Post by inejge »

motorest wrote: post #129

I know good naming is hard, and there are an awful lot of project names that clash, but naming a project uv is unfortunate due to the ubiquitous nature of libuv https://libuv.org/

I don't think it's particularly problematic, uv the concurrency library and uv the Python tool cover such non-overlapping domains that opportunities for confusion are minimal.

(The principle is recognized in trademark law -- some may remember Apple the record label and Apple the computer company. They eventually clashed, but I don't see either of the uv's encroaching on the other's territory.)

Re: A year of uv: pros, cons, and should you migrate

#142

Post by krupan »

BeetleB wrote: post #44

It seems like uv doesn't target replacing pipenv...? No mention of it in their docs and there is an open Github issue about it. I have yet to learn uv, but I intend to. Still, having to ".venv/bin/activate" to activate the virtualenv is a lot less ergonomic than "pipenv shell".

Use direnv for automatically creating, activating, and deactivating your virtual environments. I don't know how anyone lives any other way. Just put this in a .envrc file (substituting whichever python version you are using):

  layout python python3.12
  pip install --upgrade pip
  python -m pip install -r requirements.txt
Looks like direnv can be extended to use uv:

https://github.com/direnv/direnv/wiki/Python#uv

Re: A year of uv: pros, cons, and should you migrate

#143

Post by rd11235 »

BrenBarn wrote: post #126

Like so many other articles that make some offhand remarks about conda, this article raves about a bunch of "new" features that conda has had for years. > Being independent from Python bootstrapping Yep, conda. > Being capable of installing and running Python in one unified congruent way across all situations and platforms. Yep, conda. > Having a very strong dependency resolver. Yep, conda (or mamba). The main thing…

You didn’t mention an important point: speed.

Suppose conda had projects. Still, it is somewhat incredible to see uv resolve + install in 2 seconds what takes conda 10 minutes. It immediately made me want to replace conda with uv whenever possible.

(I have actively used conda for years, and don’t see myself stopping entirely because of non Python support, but I do see myself switching primarily to uv.)

Re: A year of uv: pros, cons, and should you migrate

#144

Post by oefrha »

epistasis wrote: post #138
BrenBarn wrote: post #126

Like so many other articles that make some offhand remarks about conda, this article raves about a bunch of "new" features that conda has had for years. > Being independent from Python bootstrapping Yep, conda. > Being capable of installing and running Python in one unified congruent way across all situations and platforms. Yep, conda. > Having a very strong dependency resolver. Yep, conda (or mamba). The main thing…

These are good points. But I think there needs to be an explanation why conda hasn't taken off more. Especially since it can handle other languages too. I've tried to get conda to work for me for more than a decade, at least once a year. What happens to me: 1) I can't solve for the tools I need and I don't know what to do. I try another tool, it works, I can move forward and don't go back to conda 2) it takes 20-60 m…

Conda is the dreaded solution to the dreadful ML/scientific Python works-on-my-computer dependency spaghetti projects. One has to be crazy to suggest it for anything else.

uv hardly occupies the same problem space. It elevates DX with disciplined projects to new heights, but still falls short with undisciplined projects with tons of undeclared/poorly declared external dependencies, often transitive — commonly seen in ML (now AI) and scientific computing. Not its fault of course. I was pulling my hair out with one such project the other day, and uv didn’t help that much beyond being a turbo-charged pip and pyenv.

Re: A year of uv: pros, cons, and should you migrate

#145

Post by BiteCode_dev »

BrenBarn wrote: post #126

Like so many other articles that make some offhand remarks about conda, this article raves about a bunch of "new" features that conda has had for years. > Being independent from Python bootstrapping Yep, conda. > Being capable of installing and running Python in one unified congruent way across all situations and platforms. Yep, conda. > Having a very strong dependency resolver. Yep, conda (or mamba). The main thing…

True and uv will probbaly never brings non python deps on the table.

But anaconda doesn't do inline deps, isn't a consitent experience (the typical conda project doesn't exist), is it's own island incompatible with most python ecosystem, is super slow, the yaml config is very quirky, and it's very badly documented while having poor ergonomics.

In short, anaconda solves many of those problems but brings other ones on the table.

Re: A year of uv: pros, cons, and should you migrate

#146

Post by JodieBenitez »

ashishb wrote: post #119

Has someone migrated from poetry to uv? Any benefits?

Yes. The main benefits for me and my coworkers are speed and automatic fetching of Python interpreter. It's so fast that it's a pleasure to use (same thing could be said about ruff vs. black). And the fact that it downloads the right Python interpreter specified in the project's pyproject.toml means my coworker don't have to care about installing and managing Python versions. They don't even need to have a Python installed in the first place.

Otherwise, it works pretty much like Poetry. Unfortunately Poetry is not standards-compliant with the pyproject.toml, so you'll have to rewrite it. There are tools for this, never bothered with them though.

Re: A year of uv: pros, cons, and should you migrate

#147

Post by mkl »

BrenBarn wrote: post #126

Like so many other articles that make some offhand remarks about conda, this article raves about a bunch of "new" features that conda has had for years. > Being independent from Python bootstrapping Yep, conda. > Being capable of installing and running Python in one unified congruent way across all situations and platforms. Yep, conda. > Having a very strong dependency resolver. Yep, conda (or mamba). The main thing…

Having the features is not nearly as much use if the whole thing's too slow to use. I frequently get mamba taking multiple minutes to figure out how to install a package. I use and like Anaconda and miniforge, but their speed for package management is really frustrating.

Re: A year of uv: pros, cons, and should you migrate

#148

Post by BiteCode_dev »

lysecret wrote: post #123

Really like uv too but surprised he doesn’t mention the lack of conda compliance. Some scientific packages only being available on conda is the only reason I can’t use uv (but micromamba) for some projects.

conda compiance is nearly impossible to get because the typical anaconda project doesn't exist: it's a separate ecosystem with huge variability that is by design incompatible with everything else and that no two teams use in the same way.

Re: A year of uv: pros, cons, and should you migrate

#149

Post by BiteCode_dev »

BeetleB wrote: post #44

It seems like uv doesn't target replacing pipenv...? No mention of it in their docs and there is an open Github issue about it. I have yet to learn uv, but I intend to. Still, having to ".venv/bin/activate" to activate the virtualenv is a lot less ergonomic than "pipenv shell".

You don't need to activate anything with uv, all commands do it in the venv automatically, and including uv run.

Re: A year of uv: pros, cons, and should you migrate

#150

Post by BiteCode_dev »

cjohnson318 wrote: post #9

Honest question: is uv more reproducible/portable than cramming your Python project into a Docker container? I've used pyenv, pip, venv, and a couple of other things, and they all work fine, at first, in simple scenarios.

I've seen a lot of docker images move to uv inside their docker file.

Use both.

Post reply on HN