Problems with Python dependency management

Original Article ↗ Hacker News Discussion ↗

Python’s dependency management is criticized as confusing and fragile, especially for beginners, because there are many overlapping tools (pip, venv, Poetry, Conda, uv, etc.) and no single, safe default workflow. Commenters note that failures often stem from ignoring basic practices like virtual environments and pinned versions, but they also argue that the ecosystem’s fragmentation and legacy behaviors make it too easy to get into “dependency hell.” Newer tools such as uv and emerging standards for lockfiles are widely seen as major improvements, yet there is little consensus on a one-size-fits-all solution.

Overall sentiment

  • Thread is split between “Python deps are fine if you follow basic practices” and “the defaults are bad, especially for beginners.”
  • Many say the article feels dated because modern tools exist; others argue the core problems (defaults, fragmentation) remain.

Virtualenvs, requirements.txt, and “basic hygiene”

  • Several insist a per-project virtualenv plus a pinned requirements file solves most real-world issues.
  • Others counter that requirements.txt is an outdated mix of hand-edited and generated content and a root cause of confusion.
  • Backwards-compatibility and long-lived “old ways” (global installs, sudo pip, pip freeze > requirements.txt) are seen as major drivers of breakage.

Tool fragmentation vs emerging tools

  • Long list of tools mentioned: pip, Poetry, PDM, Hatch, uv, pipenv, pip-tools, conda, OS package managers, etc.
  • Some see this abundance as confusing “bazaar-style” chaos; others say only a few actually manage dependencies end‑to‑end.
  • uv gets strong praise: fast, integrated (envs, locking, Python versions), good DX; some hope it becomes the de facto standard.
  • Concerns about uv: large/complex codebase, lack of smooth migration from Poetry, doesn’t solve OS-level library deps.

Beginners, defaults, and UX

  • Criticism that Python markets itself to beginners but ships with unsound defaults and confusing tooling.
  • Counterpoint: dependency management is an advanced concept; beginners should first learn programming, CLI, and version control.
  • venvs are called both “simple and sufficient” and “clunky and a major stumbling block.”
  • Rejected proposal for in-directory environments (__pypackages__-style) is cited as a missed onboarding improvement.

Locking, upgrades, and version hell

  • Lockfile workflows (pip-tools, uv compile/sync, constraints files, new PEPs for lockfiles and dependency groups) are highlighted as key to reproducibility.
  • Updating dependencies is described as the real pain point, especially with conflicting sub-dependency constraints and scientific/ML stacks.
  • Some argue Python’s dynamic import model and shared global module state make “multiple versions of the same library” techniques harder than in Java-like ecosystems.

Workarounds and ecosystem quirks

  • Common mitigations: Docker/devcontainers, pyenv/asdf for interpreter versions, separating “source” requirements from locked ones, vendoring.
  • Annoyances: mismatch between import names and package names, lack of a canonical CLI package search, system vs project Python conflicts.