Switching from Pyenv to Uv

Adoption and migration experiences

• Multiple commenters report replacing pyenv (often plus pyenv-virtualenv, pipx, pip-tools, Poetry/PDM, sometimes conda) with uv across many projects and CI/CD pipelines, sometimes in a day, with few issues.
• Several use uv exclusively for personal work and prototypes; some are gradually introducing it at work while still emitting requirements.txt for colleagues who don’t want uv.
• A few are still happy with existing stacks (pyenv+poetry, pip+virtualenvwrapper, conda) and see no urgent need to switch, though they acknowledge uv’s speed and modern design.

Key advantages reported

• Major speedup in dependency resolution and installation; “minutes to seconds” is mentioned repeatedly, including on slow hardware (e.g., Raspberry Pi).
• Simpler mental model: one tool handles Python installation, venvs, dependency management, locking, building/publishing, and pipx-like “tools.”
• Good support for monorepos via “workspaces” and for cross-platform lockfiles.
• Script mode (PEP 723) and ephemeral envs make small one-off scripts and sharing scripts with non‑developers much easier.

Workflow & UX details

• Typical commands (uv python install, uv init, uv add, uv run, uv sync) are seen as easy to learn.
• uv run ensures env creation and syncing before running commands; uvx/uv tool are likened to npx/pipx.
• Inline script dependencies plus shebangs (env -S uv run --script) are highlighted as a game‑changer.
• Some integrate uv with mise to manage multi-language toolchains (Python + Node, Terraform, etc.).

Monorepos, scripts, and tools

• For monorepos, one venv can be shared for tightly-coupled libs; otherwise one per package or use of workspaces.
• JS developers find the mental model somewhat analogous to pnpm, though uv currently lacks a direct equivalent of package.json scripts (planned).

Limitations and pain points

• Lack of Python shims by default; needing uv run x.py is seen as a downside, though a --default Python and uv tool install shims partially address this.
• Some want first-class support for central, named venvs (virtualenvwrapper-style) instead of only per-project .venv.
• Extras/groups UX is confusing, especially for ML stacks (e.g., CPU vs GPU PyTorch); remembering active extras across uv sync feels tedious. Config-based group defaults help, but extras remain awkward.
• Non-Python binary deps (e.g., MKL) and complex multi-env workflows are still better handled by conda for some.
• A few report rough edges with Docker/CI documentation and WSL/VS Code performance, and note that uv is still “new” enough that online help and LLMs lag.

Scientific/ML and GPU ecosystem

• Mixed but generally positive: uv handles PyTorch/CUDA better than some tools; there’s dedicated PyTorch integration docs.
• Others still rely on conda/mamba or package-specific instructions for complex multi-platform GPU cases.
• Some argue conda‑forge‑style multi-language, multi-arch support would be a “killshot” if added.

Ecosystem, governance, and funding concerns

• Some praise uv as the de facto “fix” for Python’s UX and wish older tools would sunset; others argue that uv only papers over deeper import/packaging design flaws.
• There is recurring concern about uv’s backing by a startup/VC: worries about future monetization or “enshittification,” though many note that forking is possible (tempered by the need for Rust expertise).
• Several express skepticism that the PSF will adopt or steward an official manager, given past inaction; others think a PSF-backed tool would be safer than reliance on a single vendor.