Problems with Python dependency management

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.