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

171–180 of 401 posts

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

#171

Post by sgt »

rd11235 wrote: post #143
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.)

Agreed. When I tried uv first I was immediately taken aback by the sheer speed. The functionality seemed OK, but the speed - woah. Inspiring. So I kept using it. Got used to it now.

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

#172

Post by froh »

einpoklum wrote: post #152
athrun wrote: post #106

Earlier quoted context omitted.

Pinning deps is a good thing, but it won't necessarily solve the issue of transitive dependencies (ie: the dependencies of requests itself for example), which will not be pinned themselves, given you don't have a lock file. To be clear, a lock file is strictly the better option—but for single file scripts it's a bit overkill.

One could indicate implicit time-based pinning of transitive dependencies, using the time point at which the dependended-on versions were released. Not a perfect solution, but it's a possible approach.

isn't that quite exactly what the above does?

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

#173

Post by greazy »

optionalsquid wrote: post #169
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…

Besides being much slower, and taking up much more space per environment, than uv, conda also has a nasty habit of causing unrelated things to break in weird ways. I've mostly stopped using it at this point, for that reason, tho I've still had to reach for it on occasion. Maybe pixi can replace those use cases. I really should give it a try. There's also the issue the license for using the repos, which makes it risky…

As far as I understand, the conda-forge distribution and the channel solves a lot issues. But it might not have the tools you need.

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

#174

Post by aragilar »

nchagnet wrote: post #161
epistasis wrote: post #138

Earlier quoted context omitted.

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…

Add to that the licensing of conda. In my company, we are not allowed to use conda because the company would rather not pay, so might as well use some other tool which does things faster.

conda (the package) is open source, it's the installer from Anaconda Corp (nee ContinuumIO) and their package index that are a problem. If you use the installer from https://conda-forge.org/download/, you get the conda-forge index instead, which avoids the license issues.

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

#175

Post by mufasachan »

oefrha wrote: post #144
epistasis wrote: post #138

Earlier quoted context omitted.

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…

Eh, ML/scientific Python is large and not homogeneous. For code that should work on cluster, I would lean towards a Docker/container solution. For simpler dependancy use cases, pyenv/venv duo is alright. For some specific lib that have a conda package, it might be better to use conda, _might be_.

One illustration is the CUDA toolkit with torch install on conda. If you need a basic setup, it would work (and takes age). But if you need some other specific tools in the suite, or need it to be more lightweight for whatever reason then good luck.

btw, I do not see much interest in uv. pyenv/pip/venv/hatch are simple enough to me. No need for another layer of abstraction between my machine and my env. I will still keep an eye on uv.

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

#176

Post by greazy »

bitvoid wrote: post #139
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…

> The main thing conda doesn't seem to have which uv has is all the "project management" stuff. Pixi[1] is an alternative conda package manager (as in it still uses conda repositories; conda-forge by default) that bridges this gap. It even uses uv for PyPI packages if you can't find what you need in conda repositories. 1: https://pixi.sh

Pixi goes a step further, they host mirrors of a lot of the important conda channels!

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

#177

Post by aragilar »

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…

It's worth noting that uv does not use pip, and it is entirely possible (as noted by uv's existence) to write a new installer that uses PyPI. The conflicts between pip, conda, and any other installers is all about one (or more) installers not having a complete view of the system, typically by having different packaging formats/indices/metadata.

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

#178

Post by kyawzazaw »

thisgoodlife wrote: post #80
svachalek wrote: post #67

Earlier quoted context omitted.

This works if you only have one python project on your system, but most python developers need virtual environments to deal with various projects.

I create a .venv directory for each project(even for those test projects named pytest, djangotest). And each project has its own requirements file. Personally, Python packaging has never been a problem.

it was a massive problem at our company's hackathon. just so many hours wasted

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

#179

Post by otabdeveloper4 »

barosl wrote: post #43

A very well written article! I admire the analysis done by the author regarding the difficulties of Python packaging. With the advent of uv, I'm finally feeling like Python packaging is solved. As mentioned in the article, being able to have inline dependencies in a single-file Python script and running it naturally is just beautiful. #!/usr/bin/env -S uv run # /// script # dependencies = ['requests', 'beautifulsoup4…

> I'm finally feeling like Python packaging is solved

Not really: https://github.com/astral-sh/uv/issues/5190

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

#180

Post by wiseowise »

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…

https://docs.conda.io/projects/conda/user-guide/getting-star...

> To bootstrap a conda installation, use a minimal installer such as Miniconda or Miniforge.

> Conda is also included in the Anaconda Distribution.

Bam, you’ve already lost me there. Good luck getting this approved on our locked down laptops.

No pip compatibility? No venv compatibility? Into the trash it goes, it’s not standard. The beauty of uv is that it mostly looks like glue (even though it is more) for standard tooling.

Post reply on HN