You still use it only once per project in normal workflows. And if you need to go beyond that, you'd have the same problem with Rust, at a minimum; it can't read your mind and install into the correct venv. It only seems to be doing that because it made one and assumes it will use that one.
If you like the per-project venv workflow, and like having it in a specific place (whether that's relative to the project root, or a parallel named venv in `~/.local` somewhere, or anything else), you can set that up as part of your project initialization, too.
Going back to your first comment:
> because of constant friction: pip, pyenv, poetry, pyproject.toml, rye - wtf?
This complaint makes little sense because it mixes and matches things from different categories. `pyproject.toml` isn't even a tool, but a config file that several other tools will rely on - including uv. Poetry and Rye are specifically trying to do the same thing uv is - in fact, Rye is uv's predecessor. Pyenv is for making separate installations of Python - it works alongside venvs, not as an alternative. Pip is just an installer; it's not meant to be compared to full project workflow tools or even to just "package managers".
Expecting one tool to work for everyone is a mistake because of the sheer variety of use cases out there. At the very least, people who only want to install Python applications and libraries are very different from those who seek to distribute their own work. (People in the first group might not even write Python code!)
> This complaint makes little sense because it mixes and matches things from different categories.
It makes all the sense, because I don’t want or have to give a shit about all of this crap.
> `pyproject.toml` isn't even a tool, but a config file
And how many of current tools understand it? Can I make pip save dependencies in it out of the box? No? Then it stays in bullshit list. Arguably it became much better these days, but I remember constant friction when pyproject.toml was just introduced.
> Poetry and Rye are specifically trying to do the same thing uv is - in fact, Rye is uv's predecessor. Pyenv is for making separate installations of Python - it works alongside venvs, not as an alternative. Pip is just an installer; it's not meant to be compared to full project workflow tools or even to just "package managers".
Expecting one tool to work for everyone is a mistake because of the sheer variety of use cases out there. At the very least, people who only want to install Python applications and libraries are very different from those who seek to distribute their own work. (People in the first group might not even write Python code!)
Mistake is having thousands of disjoint tools that are stitched together with sticks and shit. I’m glad most modern programming communities got fed up with this crap and lean towards new generation of tooling that can do everything.
I’m absolutely fed up and loathe stitching together billions of half working shite to get semi decent working environment.
Environment management, testing, formatting, libraries and building in one tool should be a minimum requirement.
Environment management, testing, formatting, libraries and building in one tool should be a minimum requirement.
Poetry kind of tried that, and in doing so failed to allow for a lot of uncommon but vital corner cases. In fact the main reason I gave up on poetry and switched to uv is that uv is a lot less opinionated and happily handles my 'weird' setup and lets me plug in the tools that best serve me rather than requiring me to use it for everything. I have no doubt that uv (or at least the uv 'family') will grow to handle everything sooner or later, but by tackling one piece at a time and making the tools more or less independent also gives flexibility.
