Before focusing on this feature, you must know that pyenv does far more than managing virtualenvs, since it lets you manage also different versions and implementations (e.g. CPython, PyPy...) of Python interpreter, whatever is the ones installed on your system.
- testing a different Python version than the ones installed, without taking any risk of tampering your system or needing for a virtual machine
- when targeting containerized applications (in which you are free to choose whatever Python version you want/need in the container, without any concern about the host environment), being able to work in the exact same context as the production one
Of course, you can create virtualenvs as usual with pyenv, for any Python version installed under its control.
It also lets you set which Python version or virtualenv must be used in a given project or workspace. As soon as you cd in the corresponding file tree, pyenv will automatically activate the right virtualenv (and deactivate the active one if any) and the
associated Python interpreter. It does the reverse (i.e. deactivating it) when leaving the tree. The magic is done by storing the Python interpreter or virtualenv name in a hidden file (namely .python-version) at the root of the related file tree. The pyenv
shell plugins look for this file by climbing the file tree when you navigate in the dirs and does what it has to do accordingly.
What's very important is that pyenv does not touch a bit of your system wide Python interpreters, but uses a mechanism of shims to masquerade them and redirect the flow to installations located under your home dir.
Even if you don't play with different Python version, IMHO pyenv deserves a look, if only for its automatic virtualenv switching capability.
PS: I'm not affiliated in anyway with pyenv creators, but just a happy user for a while now
🙂