What Reddit taught me about why people switch to uv

A thread titled “But really, why use uv?” landed on r/Python and pulled 476 upvotes. The original poster wasn’t antagonistic. They used Python casually, installed packages two or three times a month, and couldn’t see why uv was worth adding to a setup that already worked.

The comments convinced them. Reading through the top responses surfaces something the standard uv pitch misses: the compelling case for casual users is not the same as the compelling case for power users.

Docker builds shrink where it hurts

The most-repeated argument: Docker. Even developers who rarely touch Python environments build container images in CI. Base images rebuild on every dependency change, and pip install -r requirements.txt adds 30-90 seconds to each cold build.

uv in a Dockerfile shrinks that to 2-5 seconds on a warm cache. The layer containing packages stays cached more reliably because uv’s lockfile is more stable than a requirements file. This is felt immediately and requires no change to how you write Python—only how you build the container.

Python version management stops being a puzzle

The pyenv setup experience is one of the most reliably painful things in Python. Shell init scripts, .python-version files, PATH ordering, pyenv global vs pyenv local—the machinery is correct but entirely exposed. Several commenters described inheriting projects where .python-version files existed but nothing on the CI server respected them.

uv manages Python versions directly, downloads them on demand, and pins them inside pyproject.toml. Switching between versions becomes uv python pin 3.13. No shell hook maintenance. No version conflicts that only surface on CI. The comparison of pyenv and uv covers what each handles.

Four tools collapse to one

The implicit Python tool stack a “casual” user maintains: pip for packages, virtualenv or venv for environments, pyenv for Python versions, and pipx for CLI tools. Each works fine in isolation, but they don’t coordinate, and every project setup requires invoking them in the right sequence with the right flags.

uv replaces all of them. uv init, uv add, uv run, and uv tool install cover the same workflows with a single binary. The complete guide to uv maps each replacement.

Scripts carry their own requirements

Several comments described the same scenario: a one-off script that needs requests or pandas but belongs to no project. The traditional answer is “activate your global venv, pip install, run the script.” The cognitive tax is real—dependencies accumulate in a shared environment, or someone creates a throwaway virtualenv they forget about within a week.

PEP 723 inline script metadata solves this. A small block at the top of the script declares dependencies, and uv run script.py handles the isolated environment automatically:

# /// script
# requires-python = ">=3.12"
# dependencies = ["requests", "pandas"]
# ///
import requests
import pandas as pd

No project directory, no virtual environment to manage, no leftover state. Writing a self-contained script covers the workflow end-to-end.

uvx runs tools without installing them

Related: uvx runs any PyPI tool in an isolated environment without a permanent install. uvx ruff check ., uvx mypy src/, uvx black myfile.py—each command runs at the requested version and leaves no global state behind.

For casual users, this answers “I need to run this tool exactly once.” The tool runs, does its job, and is gone. No pipx install housekeeping, no version drift in your global tool environment.

Lock files stop the “works on my machine” problem

Teams moving from requirements.txt to uv report one consistent change: the version-drift conversation stops. uv.lock pins every transitive dependency to a hash. uv sync on any machine, any CI runner, produces an identical environment. How to use a uv lockfile explains what is being locked and why.

The casual user who assumed this didn’t apply to them is often on a team where someone periodically breaks things by upgrading a package locally. The lockfile is the fix, and uv generates one by default.

Speed is the surface story

The standard uv pitch leads with speed—10-100x faster than pip. The benchmark is real. But the thread shows speed rarely converts a skeptic who installs packages a few times a month. What converts them is recognizing that uv addresses four or five annoyances they had quietly accepted as permanent features of Python.

The handbook’s guide to why you should try uv covers the full picture. If you’re already using Python and want to migrate step by step, the guides for requirements.txt, Poetry, and Pipenv show the specific paths.