Pyenv is for installing multiple versions of python. Virtualenvs are a layer beneath that.

It’s super useful for maintaining static versions of python, like 2.7, 3.6 and 3.7 when you have many projects that have different python requirements.

I understand how this was needed historically, when using the official installer might overwrite the Python you already had installed. But as far as I know, you can download an installer for a new version, run it, and it doesn't touch your previous installation.

For example I've had 3.7 on my macOS system for a while, installed from the official installer, not through Homebrew. I just installed 3.8, which pointed my python3 to 3.8. But my 3.7 was still there; I created an alias python3.7 to point to that. So I can run or install anything I want against 3.7 or 3.8.

Why do we still need pyenv? I'm not asking that antagonistically, I really don't understand at this point and I'm wondering if I'm missing something.

Sometimes scripts will want to invoke Python as ‘python’ and it’s easier to use pyenv to set $PATH overrides.

Thank you, that’s the first concrete reason I’ve heard. It also explains why I haven’t run into issues yet using my own aliases.

Why do you need pyenv to set PATH?

Maybe you don’t, but it’s a way of doing it.

Specifically, pyenv will dynamically and programmatically link the $PATH for the Python executables (python, pip, etc.) to the desired version as defined either by an environment variable or by the contents of a .python-version file in CWD or an ancestor thereof. The .python-version file can be checked into version control.

Honestly I haven’t used official installations before so I can’t speak to that too much. Pyenv mostly uses official builds though so it’s mostly an automated frontend to manual installs.

I like being able to specify the global and local versions for my projects and the system as a whole. I also use it as a virtualenv manager. It works well with pipenv (which I still use in anger) and vscode.

I suspect, but could be wrong, that the disconnect here is bc devs who are making open source packages need to make sure it runs on multiple different versions of Python.

If you're working on closed-source code or have tight control of your environment, it's enough to develop and run on a single version, rendering pyenv and whatnot unnecessary.

It manages interpreters, not environments. So one environment can use python 3.5, while another can use 3.8.

Poetry will use the default “python” command found on the PATH. If you’re working on multiple Python interpreters for the same project, it’s very useful to combine Poetry with Pyenv.