Sometimes you will need a different version of Python for project A versus project B.

A common scenario: Python 3.10 comes out and you want to make sure your project (and all of the upstream dependencies, libraries) work with it. With pyenv you get virtualenv isolation as well as isolation of the language itself. You can have a unique Python for each project, not just a unique virtualenv sharing the same install. This also makes benchmarking kinda fun, you can jump back and forth between versions and run the test suite to gauge if any big changes have occurred time wise.

Personally, I love idempotent environments that I can create and destroy on a whim. Something go wrong? Package install failed half way through and left clutter? Destroy the directory, make new pyenv/virtenv and install again. Leaves little room for doubt.

I used to share global pythons but as I started to take on more and more consulting projects it became imperative to keep them completely isolated.

Ok, got it. Haven’t felt the need for it because I’m pretty conservative regarding language features.

But I definitely see why you‘d need it. It’s just a bit sad to me that there’s yet another tool with a potentially confusing name, orthogonal to the system Python. “Wanna get started with Python? Sure just install another Python (ignore the one that comes with your OS!) using pyenv, then it’s just a matter of getting a virtualenv and pip-installing your requirements.txt! Or was it Pipenv? Or setup.py even?“. Oh and it’s almost guaranteed that your IDE will pick the wrong instance.

It‘s just too much. I see non-Python enthusiasts struggle with this stuff on an almost dsily basis. Especially the ones who only have exposure on an irregular basis.

I wish OS distributions would just STOP providing Python packages at all.

So much about Python the language and its standard library is great. But many peripheral things (the Python 2->3 debacle first and foremost) are just badly executed.

It's solving a completely different problem, Pyenv is entirely about managing versions of Python itself, nothing to do with venvs or packages.

Say you need to have a venv but for a specific Python version:

  pyenv install 3.8.5
  pyenv shell 3.8.5
  python -m venv env
  source env/bin/activate

Now your venv is for 3.8.5, and running `source env/bin/activate` will always activate that version within the environment.

why did they call it pyenv when it has nothing to do with python environments, well at least the existing python virtual environment nomenclature

The wrinkle comes in when you need different versions of Python for different projects. e.g. Python 3.6 for one, 3.10 for another.

So what’s the actual problem? You can install multiple python versions and use the correct one when creating the venv.

pyenv helps you install and manage those multiple python versions.

I don't use pyenv and have multiple python versions installed (and use them via venv per project). If you don't need to designate one as a global/system Python (which I don't), is there any reason to use pyenv?

If your process to install a specific Python version for a project, independent of system Python, is as fast and simple as `pyenv install 3.9.7`; and if you don't work in a team where having `.python-version` file in the project will download, install and set the exact Python version required: you don't need pyenv.

`python3 -m venv venv` will use whichever minor version of Python 3 that `python3` currently points to. If you are working on multiple projects that span different Python 3 minor versions, pyenv makes the process of switching between versions much easier. You would activate the specific version you need with pyenv then use `python -m venv venv` to create the virtual environment using that specific version. It's not one or the other, but they work nicely together.