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

Uv's killer feature is making ad-hoc environments easy

valatka.dev

Post reply on HN
Print view View original

71–80 of 428 posts

Re: Uv's killer feature is making ad-hoc environments easy

#71

Post by zo1 »

mplewis wrote: post #19
poincaredisk wrote: post #14

Earlier quoted context omitted.

I never used anything other than pip. I never felt the need to use anything other than pip (with virtualenv). Am I missing anything?

Pip only has requirements.txt and doesn't have lockfiles, so you can't guarantee that the bugs you're seeing on your system are the same as the bugs on your production system.

The requirements.txt file is the lockfile. Anyways, this whole obsession with locked deps or "lockfiles" is such an anti-pattern, I have no idea why we went there as an industry. Probably as a result of some of the newer stuff that is classified as "hipster-tech" such as docker and javascript.

Re: Uv's killer feature is making ad-hoc environments easy

#73

Post by epistasis »

riwsky wrote: post #52

Heck, you can get even cleaner than that by using uv’s support for PEP 723’s inline script dependencies: # /// script # requires-python = ">=3.12" # dependencies = [ # "pandas", # ] # /// h/t https://simonwillison.net/2024/Dec/19/one-shot-python-tools/

And for the Jupyter setting, check out Trevor Manz's juv:

https://github.com/manzt/juv

Re: Uv's killer feature is making ad-hoc environments easy

#74

Post by zo1 »

mosselman wrote: post #30
remus wrote: post #22

Earlier quoted context omitted.

Pip doesn't resolve dependencies for you. On small projects that can be ok, but if you're working on something medium to large, or you're working on it with other people you can quickly get yourself into a sticky situation where your environment isn't easily reproducible. Using uv means your project will have well defined dependencies.

Oh wow it doesn’t? What DOES it do then? As I commented here just now I never got pip. This explains it.

The guy doesn't know what he's talking about as pip certainly has dependency resolution. Rather get your python or tech info from a non-flame-war infested thread full of anti-pip and anti-python folk.

Re: Uv's killer feature is making ad-hoc environments easy

#76

Post by remus »

mianos wrote: post #60
remus wrote: post #22

Earlier quoted context omitted.

Pip doesn't resolve dependencies for you. On small projects that can be ok, but if you're working on something medium to large, or you're working on it with other people you can quickly get yourself into a sticky situation where your environment isn't easily reproducible. Using uv means your project will have well defined dependencies.

https://pip.pypa.io/en/stable/topics/dependency-resolution/

My bad, see PaulHoule's comment for what I was getting at.

Re: Uv's killer feature is making ad-hoc environments easy

#77

Post by PaulHoule »

curiousgal wrote: post #56
PaulHoule wrote: post #51

Earlier quoted context omitted.

I can't see why anyone is using Conda in 2025. In 2018, yeah, pip (now uv) was hard and you could get a "just works" experience installing Tensorflow + NVIDIA on Conda. In 2023 it was the other way around and it still is.

Well, when you're building python packages that have non python dependencies and a big chunk of your users are on Windows, conda is the only option, even in 2025 :) Examples include, quant libraries, in-house APIs/tools, etc.

Circa 2018, I figured out how to pack up the CUDA libraries inside conda for Windows so I could have different conda environments with different versions of CUDA which was essential back then because if you had a model that was written w/ a certain version of Tensorflow you had to have a matching CUDA and if you used NVIDIA's we-need-your-email-address installers you could only have one version of CUDA installed at a time.

Worked great except for conda making the terrible mistake of compressing package files with bzip2 which took forever to decompress for huge packages.

I see no reason you can't install any kind of non-Python thing that a Python system wants with uv because a wheel is just a ZIP file, so long as it doesn't need to be installed in a particular place you can just unpack it and go.

Re: Uv's killer feature is making ad-hoc environments easy

#78

Post by PaulHoule »

amelius wrote: post #65
curiousgal wrote: post #56

Earlier quoted context omitted.

Well, when you're building python packages that have non python dependencies and a big chunk of your users are on Windows, conda is the only option, even in 2025 :) Examples include, quant libraries, in-house APIs/tools, etc.

Conda worked for me in the past, but at some point I was getting inexplicable segfaults from Python scripts. I switched back to just pip and everything worked fine again. And installation was much faster.

That was basically my experience. At one time conda made my life easier, eventually it made it impossible.

Re: Uv's killer feature is making ad-hoc environments easy

#79

Post by jph00 »

NeutralCrane wrote: post #54
curiousgal wrote: post #33

uv has does not (nor do they plan to add) support for conda, and that is a deal-breaker.

Why would it be a deal breaker? uv would replace conda. And I hope it does. Conda has been such a headache for me when I've used it in the past. If the Python (particularly ML/academic community) could move on from conda it would be a great thing.

uv can’t replace conda, any more than it can replace apt or nix.

Conda packages general binary packages, not just python packages. uv is just python packages.

Re: Uv's killer feature is making ad-hoc environments easy

#80

Post by RobinL »

stevage wrote: post #26

As a NodeJS developer it's still kind of shocking to me that Python still hasn't resolved this mess. Node isn't perfect, and dealing with different versions of Node is annoying, but at least there's none of this "worry about modifying global environment" stuff.

I've only recently started with uv, but this is one thing it seems to solve nicely. I've tried to get into the mindset of only using uv for python stuff - and hence I haven't installed python using homebrew, only uv.

You basically need to just remember to never call python directly. Instead use uv run and uv pip install. That ensures you're always using the uv installed python and/or a venv.

Python based tools where you may want a global install (say ruff) can be installed using uv tool

Post reply on HN