Pyenv – lets you easily switch between multiple versions of Python

Original Article ↗ Hacker News Discussion ↗

Python developers weigh the benefits of pyenv for managing multiple interpreter versions against its complexity, especially the need to compile Python from source and the subtle failures that can result. Many find pyenv invaluable for matching exact runtimes across projects and OSes, while others prefer simpler or broader tools such as built‑in `venv`, Conda, Docker images, Nix, or multi-language managers like asdf and mise. Across the thread runs a broader unease with Python’s packaging and environment story, with consensus that there is no silver bullet and that solutions must be chosen based on experience level and deployment needs.

Role of pyenv

  • Used to install and switch between multiple Python versions, independent of the system Python.
  • Common workflows:
    • pyenv for interpreter versions → venv or pyenv-virtualenv for environments → Poetry/PDM/pip-tools for deps.
    • Matching production runtimes (e.g., specific 3.x.y) or old/new versions on the same machine.
  • Some use it to build optimized interpreters (LTO, native CPU flags) or to keep system site-packages clean.

Critiques & Caveats of pyenv

  • Major concern: it usually compiles CPython from source, which:
    • Requires build toolchains and libraries; often fails on macOS and Linux without careful setup.
    • Increases CI time and image size when used inside containers.
  • Shims add another layer where PATH / resolution bugs can hide.
  • Some ops/devs report repeatedly fixing “mysterious” Python issues by removing pyenv; view it as a wrapper that adds failure modes and is better suited for experts than beginners.
  • Others counter that building Python is trivial, have used pyenv for years without trouble, and value fine-grained control.

Alternatives for Python Versions & Envs

  • System + venv: Many advocate python3.X -m venv .venv plus requirements files as enough for most work; simple and built-in.
    • Counterpoint: venv only uses already-installed interpreters and often symlinks to them, so OS/installer upgrades can silently change the runtime.
  • Multi-language managers: asdf and mise manage Python alongside Node, Ruby, etc.; mise is favored by some for performance and nicer CLI, often reusing asdf/pyenv plugins.
  • Conda/mamba/pixi: Still popular where non-Python binaries (CUDA, geospatial stack) are needed; pixi adds lockfiles and PyPI support (via uv).
  • Docker / Nix:
    • Docker widely used to sidestep host Python issues, especially with NVIDIA base images for ML.
    • Nix highlighted as one of the few options that can truly reproduce full environments (Python + system libs) over time.

Python Packaging Meta

  • Many complain about fragmentation: pip, venv, virtualenv, conda, poetry, PDM, pipenv, Rye, uv, pipx, etc.
  • Consensus that there is no single “silver bullet,” especially for beginners; recommendations range from “just use venv” to “just use Docker” to “use Nix if you can tolerate the complexity.”