- Putting .venv automatically into the project directory
- Installing dependencies with pyproject.toml
- Installing any Python version
- Fast pip installs
- uvx (like npx)
- Ruff formatter and linter, made by the same people
Python used to give me a headache, now I tend to reach for it more often, exclusively thanks to uv
Python was essentially dead for me outside of simple scripts, because of constant friction: pip, pyenv, poetry, pyproject.toml, rye - wtf? Now it's python3 -m pip3 install --user uv; uv init; uv add <package> and I'm good to go. Or amazing uvx <package>. Finally someone understands how it is supposed to be done.
`python3 -m pip install <package>' to install it?
And `python3 -m <package>' to run it?
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.
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.
Won't update your pyproject.toml and lock file
'python3 -m <package>' to run it?
Won't install the dependencies you need or set up an insolated environment <package>. 'uvx <package>' will create a venv, make sure you have all the dependencies that <package> needs and run <package>
When they talk about why they like the tool, they say things like "it's not itself written in Python" (sometimes they even seem to think Rust specifically is important), and "it's an all-in-one integrated tool that takes care of all my needs".
But when they talk about what they like about the tool, it's stuff that doesn't actually depend on the prior facts.
People have lots of different ideas about where venvs should go. Choosing an entire tool suite because it agrees with you on this point seems rather sketchy to me. (Obviously you specifically have other reasons, but still.) Managing venvs isn't hard. I use a couple of shell functions in my .bash_aliases to do it the way I want:
# Activate the local venv, which is specially named/located.
alias activate-local="source .local/.venv/bin/activate"
# Run an acceptance test in the local private folder.
alias try-it="(cd .local/ && source run-acceptance-test)"
# PIP (the pipx-installed copy) in the current Environment.
pipe() {
if [ -z ${VIRTUAL_ENV+x} ]
then
echo "No venv active; use pip instead"
else
~/.local/bin/pip --python `which python` "$@"
fi
}
There's no reason Ruff couldn't be a separate tool, mixed and matched with the tools used for other parts of the development process. That's already how people used Black.
Similarly for most of the other jobs. In my book, prefixing `uv tool` to a command line is noise; I don't see how it's better than having separate tools. What you really get from a tool suite is an opinion about which to use.
The issues with Pip don't result from it being written in Python. They result from internal design flaws - partly just generic technical debt, but largely the long-standing assumption that you'll just copy Pip to each environment. (There's code out there that tries to use `subprocess` to run Pip even after the wheel is nominally installed; this isn't assured to work! There's also code that tries to use Pip's API, even though that doesn't actually exist and will break without warning or documentation.) Current versions of Pip have much better support for installing into a different environment from where it's located (which is part of what makes Pipx possible), but awareness is low, and `--without-pip` is not the default for `venv` (that would be really disruptive).
Even slow package resolution is, as far as I can tell, mostly not because of Pip's Python code running slowly. It has more to do with suboptimal caching behaviours and the fact that the metadata standards are so poorly done, and perhaps just some algorithmic issues. But a ton of that work is IO-bound, especially if you have to use sdists for anything (getting accurate metadata tends to involve downloading the entire sdist and building the project, even if it turns out not to be the version that should be installed).