921–930 of 1001 posts
UV lets me love using Python. There are other languages, mostly Lisp languages, that I have always liked better but my workflow with UV is so pleasant that I find myself not minding Python the language, even looking forward to using it. General comment: using Rust for utilities and libraries has revitalized Python.
I have to say that I am extremely reluctant to switch over to yet another python management system (packaging, environment, python version). Every few years someone says: this is it. Switch to poetry! Okay, I did. And, at least for some academic packages, psychopy I'm looking at you, it was a friggin disaster. so. will uv install psychopy (say version 3.2.4)?
>curl -LsSf https://astral.sh/uv/install.sh | sh Don't do this shit, especially if you were told to do this shit. If you are going to do this shit, separate the commands, read the bash script (and roll it down, if another file is downloaded, download that manually and inspect it). If you are going to ask people to do this shit, split the command into two. Someone that asks me to do something insecure is either a mali…
Nobody actually inspects binaries anyway, what's the difference?
The idea behind most package managers including apt and pip is that they help you build the software and try to make it easier for you without actually downloading and trusting binaries.
UV lets me love using Python. There are other languages, mostly Lisp languages, that I have always liked better but my workflow with UV is so pleasant that I find myself not minding Python the language, even looking forward to using it. General comment: using Rust for utilities and libraries has revitalized Python.
Earlier quoted context omitted.
One of the key tenets of uv is virtualenvs should be disposable. So barring any bugs with uv there should never be any debugging environments. Worst case just delete .venv and continue as normal.
This is a key tenets of venvs generally, uv didn't invent anything, it simply brought them under one roof and improved perf.
Earlier quoted context omitted.
But you are just using virtualenv with pip. It doesn't change any of the moving pieces except that uv is virtualenv aware and will set up / use them transparently. You've been able to have the exact same setup forever with pyenv and pyenv-virtualenv except with these nothing ever has to be prefixed. Look, uv is amazing and I would recommend it over everything else but Python devs have had this flow forever.
> But you are just using virtualenv with pip. No, you aren't. > It doesn't change any of the moving pieces It literally does, though iyt maintains a mostly-parallel low-level interface, the implementation is replaced with improved (in speed, in dependency solving, and in other areas.) You are using virtual environments (but not venv/virtualenv) and the same sources that pip uses (but not pip). > You've been able to h…
> If you ignore the parts of the flow
I don't get this, pip has worked with pyproject.toml since its standardization https://peps.python.org/pep-0621/. You don't need any constellation of tools, the only pieces that aren't provided by upstream is the version manager and the virtualenv manager. The new packaging flow has also worked with the authoritative pypa tools since their standardization https://peps.python.org/pep-0517/ https://peps.python.org/pep-0518/ https://peps.python.org/pep-0751/
Again, uv is great, I just think people are giving this one tool too much credit for the standardization process (that uv is an implementation of) that actually addressed Python packaging issues. Like for example uv run, that's all https://peps.python.org/pep-0751/
Earlier quoted context omitted.
This is a key tenets of venvs generally, uv didn't invent anything, it simply brought them under one roof and improved perf.
It should have been, but people definitely kept their venvs as pets or, worse, just used the global env.
These are tools, if you choose to hold them wrong no one can stop you. uv didn't invent the screw driver or the knife, its novelty is as a Swiss Army Knife which put them all in one.
Earlier quoted context omitted.
This is it. Switch to uv! This time for real!
It certainly isn't. See here: https://github.com/astral-sh/uv/issues/5190 And here: https://pyproject-nix.github.io/uv2nix/FAQ.html#why-doesnt-u...
I'd love for uv to lock build dependencies, but due to the dynamic nature of Python package metadata it's quite a hard problem. It'll be supported eventually though.
(I work on uv)
Earlier quoted context omitted.
> how much I prefer prepending "uv" to everything instead of activating environments You can also prepend the path to the virtual environment's bin/ (or Scripts/ on Windows). Literally all that "activating an environment" does is to manipulate a few environment variables. Generally, it puts the aforementioned directory on the path, sets $VIRTUAL_ENV to the venv root, configures the prompt (on my system that means mod…
I would very much like to know the reason why they named it bin/ here and Scripts/ there. To get some closure.
