Great question! Let’s break down your concerns about using pyenv with virtualenvwrapper clearly:

1. What does pyenv virtualenvwrapper actually do? #

When you use virtualenvwrapper alone, sourcing /usr/local/bin/virtualenvwrapper.sh ties it to your system’s default Python. But pyenv virtualenvwrapper does two key things to integrate the two tools seamlessly:

• It configures virtualenvwrapper to use the currently active pyenv Python version (instead of the system one). This means when you switch to a different Python via pyenv local or pyenv global, virtualenvwrapper will create/use virtual environments based on that version automatically.
• It sets up environment variables (like WORKON_HOME) in a way that plays nicely with pyenv’s version isolation. Your virtual environments will be properly linked to the pyenv-managed Python versions you’re using, avoiding cross-version conflicts that would happen with a standalone virtualenvwrapper setup.

2. Do I still need pyenv virtualenvwrapper if I already sourced the script? #

Short answer: Yes, if you want to leverage pyenv’s multiple Python versions with virtualenvwrapper.
If you only source /usr/local/bin/virtualenvwrapper.sh directly, virtualenvwrapper will always stick to your system Python—no matter which pyenv version you’ve activated. This defeats the purpose of using pyenv to manage different Python versions, since your virtual environments won’t be tied to the specific version you’re working with.

The correct approach is to replace your direct source line in .bash_profile with:

eval "$(pyenv virtualenvwrapper)"
# Or for faster shell startup, use the lazy version:
# eval "$(pyenv virtualenvwrapper_lazy)"

This ensures pyenv handles the virtualenvwrapper configuration dynamically, matching your active Python version every time you open a shell.

3. Do I only need to run pyenv virtualenvwrapper once per new Python installation? #

Exactly! When you install a new Python version via pyenv install <version>, running pyenv virtualenvwrapper (or pyenv virtualenvwrapper_lazy) once will set up the necessary links between that new Python and virtualenvwrapper. This ensures that when you switch to the new version, virtualenvwrapper can create environments using it without issues.

You don’t need to run it every time you open a shell—adding the eval line to your .bash_profile takes care of that automatically. The _lazy variant just delays loading virtualenvwrapper until you actually use a command like workon or mkvirtualenv, which speeds up your shell’s startup time if you don’t use virtual environments constantly.

内容的提问来源于stack exchange，提问作者Manohar