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

271–280 of 401 posts

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

#271

Post by zahlman »

claytonjy wrote: post #52

A scenario for "don't use uv" I hope none of you encounter: many nvidia libraries not packaged up in something better like torch. Here's just one example, nemo2riva, the first in several steps to taking a trained NeMo model and making it deployable: https://github.com/nvidia-riva/nemo2riva?tab=readme-ov-file#... before you can install the package, you first have to install some other package whose only purpose is to…

>whose only purpose is to break pip so it uses nvidia's package registry. This does not work with uv, even with the `uv pip` interface, because uv rightly doesn't put up with that shit.

I guess you're really talking about `nvidia-pyindex`. This works by leveraging the legacy Setuptools build system to "build from source" on the user's machine, but really just running arbitrary code. From what I can tell, it could be made to work just as well with any build system that supports actually orchestrating the build (i.e., not Flit, which is designed for pure Python projects), and with the modern `pyproject.toml` based standards. It's not that it "doesn't work with uv"; it works specifically with Pip, by trying to run the current (i.e.: target for installation) Python environment's copy of Pip, calling undocumented internal APIs (`from pip._internal.configuration import get_configuration_files`) to locate Pip's config, and then parsing and editing those files. If it doesn't work with `uv pip`, I'm assuming that's because uv is using a vendored Pip that isn't in that environment and thus can't be run that way.

Nothing prevents you, incidentally, from setting up a global Pip that's separate from all your venvs, and manually creating venvs that don't contain Pip (which makes that creation much faster): https://zahlman.github.io/posts/2025/01/07/python-packaging-... But it does, presumably, interfere with hacks like this one. Pip doesn't expose a programmatic API, and there's no reason why it should be in the environment if you haven't explicitly declared it as a dependency - people just assume it will be there, because "the user installed my code and presumably that was done using Pip, so of course it's in the environment".

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

#272

Post by DoingIsLearning »

As a dabbler (using python mostly for internal engineering tools and post processing of data) I am using uv at home but not in a professional setting.

The latest release is at 0.6.1, what is missing (roadmap/timeline wise) for uv to exist as a 1.0 release?

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

#273

Post by zahlman »

ziml77 wrote: post #115
claytonjy wrote: post #52

A scenario for "don't use uv" I hope none of you encounter: many nvidia libraries not packaged up in something better like torch. Here's just one example, nemo2riva, the first in several steps to taking a trained NeMo model and making it deployable: https://github.com/nvidia-riva/nemo2riva?tab=readme-ov-file#... before you can install the package, you first have to install some other package whose only purpose is to…

Surely you can just manually add their index, right?

Yes, but the point is that they automate the process for you, because it's finicky.

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

#274

Post by zahlman »

iandanforth wrote: post #79

Since this seems to be a love fest let me offer a contrarian view. I use conda for environment management and pip for package management. This neatly separates the concerns into two tools that are good at what they do. I'm afraid that uv is another round of "Let's fix everything" just to create another soon to be dead set of patterns. I find nothing innovative or pleasing in its design, nor do I feel that it is parti…

Pip installs packages, but it provides rather limited functionality for actually managing what it installed. It won't directly spit out a dependency graph, won't help you figure out which of the packages installed in the current environment are actually needed for the current project, leaves any kind of locking up to you...

I agree that uv is the N+1th competing standard for a workflow tool, and I don't like workflow tools anyway, preferring to do my own integration. But the installer it provides does solve a lot of real problems that Pip has.

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

#275

Post by kokada »

EdwardDiego wrote: post #230
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.

1 file, 2 files, N files, why does it matter how many files? Use a lock file if you want transitive dependencies pinned. I can't think of any other language where "I want my script to use dependencies from the Internet, pinned to precise versions" is a thing.

> 1 file, 2 files, N files, why does it matter how many files?

One file is better for sharing than N, you can post it in a messenger program like Slack and easily copy-and-paste (while this becomes annoying with more than one file), or upload this somewhere without needing to compress, etc.

> I can't think of any other language where "I want my script to use dependencies from the Internet, pinned to precise versions" is a thing.

This is the same issue you would have in any other programming language. If it is fine for possibly having breakage in the future you don't need to do it, but I can understand the use case for it.

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

#276

Post by baq »

BossingAround wrote: post #196
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…

This looks horrible for anything but personal scripts/projects. For anything close to production purposes, this seems like a nightmare.

Don’t use it in production, problem solved.

I find this feature amazing for one-off scripts. It’s removing a cognitive burden I was unconsciously ignoring.

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

#277

Post by kokada »

froh wrote: post #172
einpoklum wrote: post #152

Earlier quoted context omitted.

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?

I think OP was saying to look at when the package was build instead of explicitly adding a timestamp. Of course, this would only work if you speficied `requests@1.2.3` instead of just `requests`.

This looks like a good strategy, but I wouldn't want it by default since it would be very weird to suddenly having a script pull dependencies from 1999 without explanation why.

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

#278

Post by aragilar »

sieve wrote: post #195
aragilar wrote: post #191

Earlier quoted context omitted.

That problem is very much not pip (pip is only the installer), the issue is: * We have a conflict between being easy to use (people don't need to work out which version of cuda/which gpu settings/libraries/etc. to use) vs install size (it's basically the x86 vs arm issue, except at least 10 fold larger). Rather than making it the end-users problem, packages bundle all possible options into a single artifact (MacOS do…

> people don't need to work out which version of cuda/which gpu settings/libraries/etc. to use This is not true in my case. The regular pytorch does not work on my system. I had to download a version specific to my system from the pytorch website using --index-url. > packages bundle all possible options into a single artifact Cross-platform Java apps do it too. For e.g., see https://github.com/xerial/sqlite-jdbc . Bu…

That's a pytorch issue. The solution is, as always, build from source. You will understand how the system is assembled, then you can build a minimal version meeting your specific needs (which, given wheels are a well-defined thing, you can then store on a server for reuse).

Cross-OS (especially with a VM like Java or JS) is relatively easy compared to needing specific versions for every single sub-architecture of a CPU and GPU system (and that's ignoring all the other bespoke hardware that's out there).

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

#279

Post by __s »

hannibalhorn wrote: post #265
EdwardDiego wrote: post #230

Earlier quoted context omitted.

1 file, 2 files, N files, why does it matter how many files? Use a lock file if you want transitive dependencies pinned. I can't think of any other language where "I want my script to use dependencies from the Internet, pinned to precise versions" is a thing.

If there's a language that does this right, all ears? But I havn't seen it - The use case described is for a small one off script for use in CI, or a single file script you send off to a colleague over Slack. Very, very common scenario for many of us. If your script depends on a => c b => c You can pin versions of those direct dependencies like "a" and "b" easy enough, but 2 years later you may not get the same versi…

Rust tends to handle this well. It'll share c if possible, or split dependencies. Cargo.lock preserves exact resolution

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

#280

Post by kokada »

zelphirkalt wrote: post #219
0xCMP wrote: post #136

Earlier quoted context omitted.

I think this is an awesome feature and will probably a great alternative to my use of nix to do similar things for scripts/python if nothing else because it's way less overhead to get it running and playing with something. Nix for all it's benefits here can be quite slow and make it otherwise pretty annoying to use as a shebang in my experience versus just writing a package/derivation to add to your shell environment…

Will nix be slow after the first run? I guess it will have to build the deps, but in a second run should be fast, no?

`nix-shell` (that is what the OP seems to be referring) is always slow-ish (not really that slow if you are used with e.g.: Java CLI commands, but definitely slower than I would like) because it doesn't cache evaluations AFAIK.

Flakes has caching but support for `nix shell` as shebang is relatively new (nix 2.19) and not widespread.

Post reply on HN