Earlier quoted context omitted.
ROCm. About 40%. But there is duplication there as well. Two 16GB folders containing the exact same version.
Sounds like a great use case for ZFS’s deduplication at block level.
or, you know.. symlinks
A year of uv: pros, cons, and should you migrate
31–40 of 401 posts
Re: A year of uv: pros, cons, and should you migrate
#32Earlier quoted context omitted.
ROCm. About 40%. But there is duplication there as well. Two 16GB folders containing the exact same version.
Sounds like a great use case for ZFS’s deduplication at block level.
I use ZFS everywhere EXCEPT on this drive. Not willing to have ZFS on the primary drive till native support lands in the kernel (so, never).
Re: A year of uv: pros, cons, and should you migrate
#33I thought this was going to be about the UV rays from the sun... But it's another python package manager. We're running out of names.
Were you considering migrating to ultraviolet light? Vitamin D is indeed important, but that mutagenesis is no joke. I'd suggest against it.
I read it as "should you migrate to a more or less sunny region".
Re: A year of uv: pros, cons, and should you migrate
#34Earlier quoted context omitted.
uv implements its own resolution logic independently of pip. Maybe your various LLM libraries are pinning different versions of Torch? Different Python versions each need their own separate Torch binaries as well. At least with uv you don't end up with separate duplicate copies of PyTorch in each of the virtual environments for each of your different projects!
> Different Python versions each need their own separate Torch binaries as well Found this the hard way. Something to do with breakage in ABI perhaps. Was looking at the way python implements extensions the other day. Very weird.
> 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 therefore don't need to be duplicated as many times (either on the index or on the installing client). Torch doesn't build these wheels for whatever reason, so you end up with multiple slightly different but functionally identical builds for each version of Python you're using.
TL;DR: This happens because of an interaction between two patterns that Python makes very easy: using multiple Python versions, and building/installing binary extensions. In a sense, it's a symptom of Python's success: other ecosystems don't have these problems because they have far fewer people running multiple configurations simultaneously.
Re: A year of uv: pros, cons, and should you migrate
#35Re: A year of uv: pros, cons, and should you migrate
#36Earlier quoted context omitted.
> Different Python versions each need their own separate Torch binaries as well Found this the hard way. Something to do with breakage in ABI perhaps. Was looking at the way python implements extensions the other day. Very weird.
> 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.
Re: A year of uv: pros, cons, and should you migrate
#37Can 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 new packages, but rarely update it, unless I feel like a spring cleaning. And I like knowing that I have the same environment across all my machines, so I don’t have to think about if I’m running the same script or notebook on a different machine today.
The idea of a new environment for each of my related “projects” just doesn’t make sense to me. But, I’m open to learning a new workflow.
Addition: I don’t run other’s code, like pretrained models built with specific package requirements.
Re: A year of uv: pros, cons, and should you migrate
#38Earlier quoted context omitted.
ROCm. About 40%. But there is duplication there as well. Two 16GB folders containing the exact same version.
Does uv have any plans for symlink/hardlink deduplication?
Not sure. The simplest solution is to store all files under a hashed name and sym/hardlink on a case to case basis. But some applications tend to behave weirdly with such files. Windows has its own implementation of symlinks and hardlinks. They simply call it something else. Perhaps portability could be an issue.
Re: A year of uv: pros, cons, and should you migrate
#39Earlier 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.
python just didn't have much momentum until relatively recently, despite it's age. There are efforts to speed it up going on now backed by Microsoft.
For pypy it's in a weird spot as the things it does fast are the ones you'd usually just offload to a module implemented in C
Re: A year of uv: pros, cons, and should you migrate
#40Is uv better than micromamba? I tried using uv once and got some big ugly error I don't remember, and that was the end of that, whereas mm just worked (perhaps due to my familiarity). It was a project with the usual situation, i.e., torch, numpy, cuda support, nvcc, all had to play nicely together and satisfy requirements.txt.
I used uv for the first time a few months ago and it was a total revelation (previously I used venv and pip). I would be happy if pip itself and conda went away (although that won't happen).