←back to thread

Using uv with PyTorch

(docs.astral.sh)
167 points charliermarsh | 10 comments | | HN request time: 1.416s | source | bottom
1. alex_suzuki ◴[] No.42192428[source]
In a nutshell, what do I gain from switching to uv from my current workflow, which is: 1) create a venv (`python3.xx -m venv venv`) 2) install packages from a requirements.txt into that venv?

One limitation I know of are the inability to detect stale packages.

Apart from „blazing fast“, which I‘m not convinced it really matters to me as I rarely touch the dependencies, what are the main reasons why uv is gaining traction?

replies(4): >>42192436 #>>42192507 #>>42192711 #>>42198294 #
2. alex_suzuki ◴[] No.42192436[source]
PS: one thing I like about my current workflow is no extra tools needed, base python install is all that‘s required.
replies(1): >>42193311 #
3. reubenmorais ◴[] No.42192507[source]
You get correct version resolution (checking compatibility across the entire tree of deps-of-deps, including against different Python versions) and a lock file which represents a global state of the entire tree and gives you reproducibility of a working setup.
replies(1): >>42192563 #
4. gugagore ◴[] No.42192563[source]
Does pip-compile do the same? Or what's the difference?
replies(1): >>42192578 #
5. reubenmorais ◴[] No.42192578{3}[source]
pip-compile, poetry, Pipenv, et al all try do roughly the same, with various caveats and design differences (e.g. Pipenv is not meant to be used in libraries, only applications). uv is the latest kid in the block.
6. imjonse ◴[] No.42192711[source]
One reason is that it is not just for project venv/deps management but can replace other tools like pipx and pyenv for most scenarios.
7. JimDabell ◴[] No.42193311[source]
It’s similar with uv. You have exactly one dependency on the host system – it’s just uv instead of Python. uv will then obtain the correct version of Python for your project. And uv is easier to install than Python – it’s literally just one binary.
replies(1): >>42196535 #
8. alex_suzuki ◴[] No.42196535{3}[source]
Interesting, thanks for pointing that out. Will give it a try.
9. infamia ◴[] No.42198294[source]
You might gain a couple of things...

No need to activate venvs and the almost inevitable Python pathing "murder mysteries". uv installs in venvs first, and only then someplace else (e.g., globally).

No more clunky typing `python -m pip install foo` even when you have activated your venv (or you think you have). `uv pip install foo` is nicer and easier to remember.

uv add will add new dependencies to your pyproject.toml so you don't have to.

uv can setup skeletons for new projects in a nice, modern way

For older projects, you can have uv to resolve dependencies as of a certain date. I imagine this is great for older projects, especially with numerous dependencies.

It might remove the need for pyenv or the need to rely on your system provided Python, since uv can install Python for your project.

Cross-platform lock files

I've just started looking in to uv, so maybe my list isn't complete/very good. Some down sides include, it's still green (has some bugs naturally and lacks some features) and some might not trust/like that it's VC backed.

replies(1): >>42212940 #
10. alex_suzuki ◴[] No.42212940[source]
> For older projects, you can have uv to resolve dependencies as of a certain date. I imagine this is great for older projects, especially with numerous dependencies.

Interesting. I imagine this is a selling point for corporate environments.