Python Has Too Many Package Managers

Original Article ↗ Hacker News Discussion ↗

Python’s growing ecosystem of package managers—from pip and virtualenv to Poetry, PDM, Conda, Rye, uv, and Nix-based setups—is seen by many as both a strength and a source of chaos. Commenters compare these tools’ speed, reliability, standards compliance, and suitability for use cases like machine learning or long‑term maintainability, often contrasting them with Rust’s Cargo or PHP’s Composer. A recurring theme is the tension between simple, “boring” workflows using pip/venv and the desire for reproducible, secure, single-tool solutions that hide complexity and reduce breaking changes.

Overall sentiment

  • Many agree Python packaging is fragmented and confusing compared to ecosystems like Rust’s Cargo or PHP’s Composer.
  • Some argue the situation “used to be simple” with just pip, and that successive tooling changes normalized breaking changes.
  • Others push back: for many day‑to‑day projects, basic tools still work fine.

pip + venv vs “modern” tools

  • A sizable group reports long‑term success with pip + venv (+ sometimes pip-tools or pyenv), treating venvs as disposable and using requirements.in + compiled requirements.txt.
  • Critics say this workflow often fails teams in practice: missing locks, drifting transitive deps, production‑only failures, and extra homegrown scripts.
  • There’s debate on whether “just nuke the venv and reinstall” is acceptable or wasteful and fragile.

Poetry, PDM, Hatch, uv, Rye, etc.

  • Poetry has many fans for lockfiles, reproducibility, multi‑Python support, and overall ergonomics; detractors cite instability, breaking changes, and performance issues.
  • PDM gets praise for being PEP‑compliant, playing well with pyproject.toml, and providing in‑project venvs.
  • pip-tools is liked as a minimal layer for generating fully pinned requirements, though some dislike its own dependency bloat.
  • uv is described as extremely fast and “transformative”; some already pair it with other tools, others think it’s not yet “prime time.”
  • Rye is seen as a promising meta‑tool now using uv under the hood; it’s characterized as young but sane and fast.
  • Hatch is mentioned positively but under‑explored in the thread.

Conda, Nix, and scientific/ML use

  • Conda is called “best for ML” by some, but others share horror stories of ultra‑slow solving, broken envs, confusing channel priority, and invasive installs.
  • A few strongly prefer Nix (sometimes via wrappers) as the “be‑all‑and‑end‑all” for reliable Python environments and non‑Python deps.

Reproducibility, security, and dependency graphs

  • Strong consensus that pinning full dependency trees and using lockfiles is essential for long‑term reproducibility; simply “pull latest” is widely criticized.
  • Concerns about frequent breaking changes, accumulating CVEs, and complex dependency graphs (including real-world cycles).
  • Some advocate vendoring wheels into version control to avoid supply‑chain surprises.

Ecosystem design & philosophy

  • Frustration that Python’s “one obvious way” ideal hasn’t held for packaging: multiple build backends, pyproject.toml variants, and shifting “official” tools (distutils removal, build/install, etc.).
  • Comparisons with Cargo, npm, Composer, Docker, and even Deno highlight trade‑offs between single binary builds, global vs local deps, and language vs OS package managers.