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

211–220 of 401 posts

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

#211

Post by BrenBarn »

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.)

It's true conda used to be slow, but that was mostly at a time when pip had no real dependency resolver at all. Since I started using mamba, I haven't noticed meaningful speed problems. I confess I'm always a bit puzzled at how much people seem to care about speed for things like install. Like, yes, 10 minutes is a problem, but these days mamba often takes like 15 seconds or so. Okay, that could be faster, but installing isn't something I do super often so I don't see it as a huge problem.

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

#212

Post by physicsguy »

sieve wrote: post #36
woodruffw wrote: post #34

Earlier quoted context omitted.

> Something to do with breakage in ABI perhaps. Was looking at the way python implements extensions the other day. Very weird. Yes, it's essentially that: CPython doesn't guarantee exact ABI stability between versions unless the extension (and its enclosing package) intentionally build against the stable ABI[1]. The courteous thing to do in the Python packaging ecosystem is to build "abi3" wheels that are stable and…

My use of python is somewhat recent. But the two languages that I have used a lot of - Java and JS - have interpreters that were heavily optimized over time. I wonder why that never happened with python and, instead, everyone continues to write their critical code in C/Rust. I am planning to shift some of my stuff to pypy (so a "fast" python exists, kind of). But some dependencies can be problematic, I have heard.

For scientific stuff and ML, it's because people already had libraries written in C/Fortran/C++ and so calling it directly just made sense.

In other languages that didn't happen and you don't have anywhere near as good scientific/ML packages as a result.

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

#213

Post by lmm »

BrenBarn wrote: post #121
something98 wrote: post #37

Can someone explain a non-project based workflow/configuration for uv? I get creating a bespoke folder, repo, and uv venv for certain long-lived projects (like creating different apps?). But most of my work, since I adopted conda 7ish years ago, involves using the same ML environment across any number of folders or even throw-away notebooks on the desktop, for instance. I’ll create the environment and sometimes add n…

Yeah, this is how I feel too. A lot of the movement in Python packaging seems to be more in managing projects than managing packages or even environments. I tend to not want to think about a "project" until very late in the game, after I've already written a bunch of code. I don't want "make a project" to be something I'm required or even encouraged to do at the outset.

I have the opposite feeling, and that's why I like uv. I don't want to deal with "environments". When I run a Python project I want its PYTHONPATH to have whatever libraries its config file says it should have, and I don't want to have to worry about how they get there.

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

#214

Post by physicsguy »

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…

Cross platform Java doesn't have the issue because the JVM is handling all of that for you. But if you want native extensions written in C you get back to the same problem pretty quickly.

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

#215

Post by zelphirkalt »

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…

Any flow that does not state checksums/hashsums is not ready for production and all but beautiful. But I haven't used uv yet, so maybe it is possible to specify the dependencies with hashsums in the same file too?

Actually the order of import statement is one of the things, that Python does better than JS. It makes completions much less costly to calculate when you type the code. An IDE or other tool only has to check one module or package for its contents, rather than whether any module has a binding of the name so and so. If I understand correctly, you are talking about an additional syntax though.

When mentioning a gigantic venv ... Why did they do that? Why not have smaller venvs for separate projects? It is really not that hard to do and avoids dependency conflicts between projects, which have nothing to do with each other. Using one giant venv is basically telling me that they either did not understand dependency conflicts, or did not care enough about their dependencies, so that one script can run with one set of dependencies one day, and another set of deps the other day, because a new project's deps have been added to the mix in the meantime.

Avoiding deps for small scripts is a good thing! If possible.

To me it just reads like a user now having a new tool allowing them to continue the lazy ways of not properly managing dependencies. I mean all deps in one huge venv? Who does that?? No wonder they had issues with that. Can't even keep deps separated, let alone properly having a lock file with checksums. Yeah no surprise they'll run into issues with that workflow.

And while we are relating to the JS world: One may complain in many ways about how NPM works, but it has had automatic lock file for aaages. Being the default tool in the ecosystem. And its competitors had it to. At least that part they got right for a long time, compared to pip, which does nothing of the sort eithout extra effort.

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

#216

Post by lmm »

datadeft wrote: post #205
wiseowise wrote: post #186

Earlier quoted context omitted.

Maybe because there would be blood on the streets, because people would start killing each other over atrocious build times?

Interesting. So pip install times did not make them to kill each other and the result is sometimes works, but if we wait on cargo build somehow it triggers them.

You can get pretty far without needing to run pip. Whereas you can't change anything in a rust codebase without compiling it.

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

#217

Post by zelphirkalt »

epistasis wrote: post #59
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…

One other key part of this is freezing a timestamp with your dependency list, because Python packages are absolutely terrible at maintaining compatibility a year or three or five later as PyPI populates with newer and newer versions. The special toml incantation is [tool.uv] exclude-newer: # /// script # dependencies = [ # "requests", # ] # [tool.uv] # exclude-newer = "2023-10-16T00:00:00Z" # /// https://docs.astral.…

Why didn't you create a lock file with the versions and of course hashsums in it? No version hunting needed.

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

#218

Post by oefrha »

mufasachan wrote: post #175
oefrha wrote: post #144

Earlier quoted context omitted.

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)…

Oh I'm not saying conda is a good solution for all ML/scientific. I was making the assertion that it's terrible for basically everything else.

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

#219

Post by zelphirkalt »

0xCMP wrote: post #136
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 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?

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

#220

Post by lmm »

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.

What do you do when you accidentally run pip install -r requirements.txt with the wrong .venv activated?

If your answer is "delete the venv and recreate it", what do you do when your code now has a bunch of errors it didn't have before?

If your answer is "ignore it", what do you do when you try to run the project on a new system and find half the imports are missing?

None of these problems are insurmountable of course. But they're niggling irritations. And of course they become a lot harder when you try to work with someone else's project, or come back to a project from a couple of years ago and find it doesn't work.

Post reply on HN