|
|
|
|
|
|
by DHolzer
452 days ago
|
|
|
I recently checked out UV, and it's impressively fast. However, one challenge that keeps coming up is handling anything related to CUDA and Torch. Last week, I started developing directly in PyTorch containers using just pip and Docker. With GPU forwarding on Windows no longer being such a hassle, I'm really enjoying the setup. Still, I can’t shake the feeling that I might be overlooking something critical. I’d love to hear what the HN crowd thinks about this type of env. |
|
|
https://docs.astral.sh/uv/guides/integration/pytorch/
If the platform (OS) solution works for you that's probably the easiest. It doesn't for me because I work on multiple Linux boxes with differing GPUs/CUDAs. So I've use the optional dependencies solution and it's mostly workable but with an annoyance that uv sync forgets the --extra that have been applied in the venv so that if you "uv add" something it will uninstall the installed torch and install the wrong one until I re-run uv sync with the correct --extra again. (uv add with --extra does something different) And honestly I appreciate not having hidden venv states but it is a bit grating.
There are some ways to setup machine/user specific overrides with machine and user uv.toml configuration files.
https://docs.astral.sh/uv/configuration/files/
That feels like it might help but I haven't figured out how to configure get that to help it pick/hint the correct torch flavor for each machine. Similar issues with paddlepaddle.
Honestly I just want an extras.lock at this point but that feels like too much of a hack for uv maintainers to support.
I have been pondering whether nesting uv projects might help so that I don't actually build venvs of the main code directly and the wrapper depends specifically on certain extras of the wrapped projects. But I haven't looked into this yet. I'll try that after giving up on uv.toml attempts.