Blog

A few years ago, I was working on a project where I needed to run an old Zope application under Python 2.4. Simple Python Version Management (pyenv) — which allows developers to easily switch between multiple versions of Python — sounded like exactly what I needed. But, when I discovered that the installation instructions required you to modify your shell’s initialization so pyenv could take over your $PATH, I began searching for a workaround.

I decided to install pyenv anyway. Knowing that I could still run pyenv as needed without letting it take over my shell — I skipped the shell init steps. However, it failed to build Python 2.4 because it was “too old.”

In addition to roadblocks surrounding “too old” versions of Python, there are other reasons why I don’t feel like fully embracing pyenv is worth it. Specifically:

• Either way, you’ll need to tell your editor or IDE where to find the appropriate Python executable.
• What’s going to happen when you run python? ¯\_(ツ)_/¯
• The things pyenv makes easier are not done often enough to justify altering the environment for every single command you ever run.

Install pyenv Without Letting It Take Over Your Shell

That said, there is a place in your life for pyenv, and you don’t have to let it take over your shell. Simply follow the installation instructions to get it onto your system, but instead of following the recommended steps, simply add export PYENV_ROOT="$(pyenv root)" to your shell’s environment.

With the executable installed and only the environment variable set, the pyenv command should be fully functional for things like pyenv versions or pyenv install 3.8.13. You can also get a real answer when you run which python and generally avoid other surprises.

The only time you’ll need to think about pyenv is when you start working on a project that requires a specific Python version.

Let’s go through an example from a project that requires Python 3.8.

If you simply installed pyenv, leaving your shell unchanged:

$ pyenv install 3.8.13
$ cd special_project
$ $PYENV_ROOT/versions/3.8.13/bin/python -m venv .venv
$ . .venv/bin/activate

If you installed pyenv with the officially recommended shell modifications:

$ pyenv install 3.8.13
$ cd special_project
$ pyenv local 3.8.13
$ python -m venv .venv
$ . .venv/bin/activate

If you follow the official recommendations, the command to create the virtualenv is a bit shorter (but only if you run an additional command first). Is that really worth it? Not in my opinion because, now, which python tells you nothing. Plus, going forward, because of the additional pyenv local command you ran, when you run python, you’ll get 3.8 in the special_project directory and the system version in other directories.

When you don’t allow pyenv to take over your shell, you’ll always know what’s going to happen when you run python. If you activated a virtualenv, you get that version. Otherwise, you get your preferred default version. The only downside of this approach is that you’ll need to type a slightly longer command a couple of times per year.

Happy coding! Want more best practices? Explore Six Feet Up’s blogs, and sign up for our newsletters to get tech tips in your inbox.