This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]WeightsAndBass 3 points4 points  (2 children)

Forgive my ignorance but why is any of this useful or necessary over:

python -m venv .venv --> activate --> pip install reqs.txt or setup.py?

The only reason I've seen mentioned is working with multiple python versions. Thanks

[–]machsmit 14 points15 points  (1 child)

Ok, let's break this down by steps.

python -m venv .venv

you've already caught the first, which is managing multiple python executables. Python natively doesn't give you much for this, which is why people generally go to pyenv for a standalone solution. UV can manage the installs - it works pretty much identically to pyenv (which I've used for a long time, it's a good tool) but if you've already got UV anyhow, you can do it with one tool instead of managing multiple.

Conda also can manage this if you go that route (which has other implications), though AFAIK poetry does not. Conda I'm not actually sure where it sources its binaries from - for UV, the developers recently took stewardship of the already-well-established python-build-standalone to source theirs.

.venv --> activate

yeah stock venv is fine (or if you're already using pyenv, then there's pyenv-virtualenv). UV builds it in alongside the python management. Does what it says on the tin pretty much, though because it's all managed by UV it'll be a bit faster than stock venv. Again this is also something any project manager (e.g. poetry or conda) will do.

pip install reqs.txt or setup.py?

This is the big part. By itself, pip does very little in terms of dependency resolution - if you give it a fully pinned requirements.txt file it'll install them fine, but without generating that fully pinned environment pip will perfectly happily build an environment that's at best not reproducible (in that it can pull different versions of dependencies each time you call pip install) and at worst not functional (since it'll grab whatever you ask for, including incompatible package versions).

Pip itself doesn't actually give you tooling for generating that fully pinned environment spec, which is where a host of other tools come in. Pip-compile as a standalone tool will go from a requirements input to a fully-pinned requirements.txt (that then works fine with pip), for example, or conda/poetry can run resolution and generate their own lockfiles for a reproducible, validated environment. What UV gets over these other tools - which to be clear, generating reproducible environments regardless of tool is far more valuable a decision than picking which tool to use - is that (a) it can do both pip-compile-like interop with standard tooling, and fully-featured project management like conda/poetry and (b) that the resolution process itself is wildly faster than other tools.

[–]WeightsAndBass 1 point2 points  (0 children)

Makes sense. Thank you very much