There's this weird disconnect I've noticed whenever people talk about Python project management tools in general, and especially about UV.

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
}

And then I use a simple Python wrapper to create the venv and do an editable install into it. ("Installing dependencies with pyproject.toml" is already supported in Pip, assuming you mean the project's runtime dependencies: `pip install -e .`. Support for other dependency groups defined by new PEPs will hopefully come soon.)

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).