I just ran into this myself and wanted to post back to emphasize that Virtualenv really is handy for this sort of thing. The gist of it is:
Install Virtualenv- sudo pip install virtualenv
Create a directory, anywhere, call it whatever you want. I called mine “virtualenvs”. I made mine in my home directory, and made it a hidden directory. mkdir ~/.virtualenvs && cd ~/.virtualenvs
If I want to create an environment to run Ansible 24.0.0 I could run (from my .virtualenv directory) virtualenv ansible_24
.
This command creates a directory called “ansible_24” and installs a complete Python environment there, separate from your system environment. It’s not large, we’re talking 75 Mb for a virtualenv w/ Python, pip and Ansible.
Now just activate the environment by CDing to it, cd ansible_24
and running source bin/activate
You’ll know the environment is active because your prompt will show the name of the active environment, so $ /some/dir
would change to (ansible_24) $ /some/dir
Once it’s active install the Ansible version you need, pip install ansible
(note no sudo
needed when in a virtual env)
That’s it. Now any commands ran from that shell will use the active Python environment.
When you’re done run deactivate
and you’ll go back to your system environment.
To use again just activate it, so if I were in ~/sites/mysite and wanted to use my other Ansible version I’d run source ~/.virtualenvs/ansible_24/bin/activate
and that’s it. Maybe setup an alias for that or something if you want.
If you no longer want the env around it just delete it - rm -rf ~/.virtualenvs/ansible_24
.
There’s more to it, like you can specify Python versions and that sort of thing, but for the person with umpteen hundred Trellis installs who just needs to switch back and forth, this should be plenty.
PS. For the ultimate in convenience also install Virtualenvwrapper. There’s a little config beyond the initial Pip install, but it’s just a few lines added to your zshrc, or bashrc, or whatever.
With Virtualenvwrapper setup you just run mkvirtualenv some_env_name
from anywhere on your system and it handles the rest. Then to use it you just run workon some_env_name
and it handles it.
If you really want to nerd out you can configure your terminal to run workon
whenever you CD to the specified directory.
Hopefully this is helpful. I’ve been digging into Python a bit over the past few months (it’s awesome) and have found virtualenvs to be pretty much necessary.