> Deploying Python projects almost require using a container.

Really? `apt install pipx; pipx install sphinx` (for example) worked flawlessly for me. Pipx is really just an opinionated wrapper that invokes a vendored copy of Pip and the standard library `venv`.

The rest of your post seems to acknowledge that virtual environments generally work just fine. (Uv works by creating them.)

> Sometimes you're limited by Python version and it can be non-trivial to have multiple versions installed at once.

I built them from source and make virtual environments off of them, and pass the `--python` argument to Pipx.

> If you use anything outside the standard library the only reliable way to run a script is installing it in a virtual environment. Doing that manually is a hassle and pyenv can be stupidly slow and wastes disk space.

If you're letting it install separate copies of Python, sure. (The main use case for pyenv is getting one separate copy of each Python version you need, if you don't want to build from source, and then managing virtual environments based off of that.) If you're letting it bootstrap Pip into the virtual environment, sure. But you don't need to do either of those things. Pip can install cross-environment since 22.3 (Pipx relies on this).

Uv does save disk space, especially if you have multiple virtual environments that use the same packages, by hard-linking them.

> With uv it's fast and easy to set up throw away venvs or run utility scripts with their dependencies easily. With the PEP-723 scheme in the linked article running a utility script is even easier since its dependencies are self-declared and a virtual environment is automatically managed.

Pipx implements PEP 723, which was written to be an ecosystem-wide standard.