If you ever get a situation that the default installation of python on your system is not compatible with the one you need to install a particular package? then you gotta use a trick to manage different versions of Python in same system.
I use Manjaro Linux as my Dev OS, recently I had to lay my hands on Gnu – Health which is developed on Tryton framework. One of the premium requirement for Gnu-Health is python 2.6 / 2.7. But my Manjro Linux has the default installation of Python 3. well, I managed to install Gnu- Health using some tricks that I share with you below
In order to manage different versions of Python, we need some tools as virtualenv and virtualenvwrapper. Use the following commands to install those tools
sudo pip-2.7 install virtualenv –upgrade
sudo pip install virtualenvwrapper
Now,create a “Snakepit” directory for storing all the virtualenvs.
Add the following your ~/.bashrc to enable virtualenvwrapper.
if [ -f /usr/local/bin/virtualenvwrapper.sh ]; then
elif [ -f /usr/bin/virtualenvwrapper.sh ]; then
Lets create a virtual env
Open a new shell to ensure that the virtualenvwrapper configuration is active.
The following will create a new virtualenv called Nikola5 based on Python 2.7, which will use to distribute rather than setuptools and will not give access to the global site-packages directory.
mkvirtualenv -p python2.7 –no-site-packages –distribute ~/Snakepit/somename
mkvirtualenv_help shows a full list of arguments, the -r switch can install all the packages listed in a pip requirements file into the newly created virtualenv. Very useful.
if you need support for system wide package installation then use –system-site-packages
Working on a virtualenv
To workon, or activate, an existing virtualenv do the following.
You can switch to another virtualenv at any time, just use workon envname. Your shell prompt will change while a virtualenv is being worked on to indicate which virtualenv is currently active.
While working on a virtualenv you can pip install what you need or manually install any Python libraries safe in the knowledge you will not adversely damage any other virtualenvs or the global packages in the process. Very useful for developing a new branch which may have different library requirements than the master/head.
When you are finished working in a virtualenv you can deactivate it by simply executing:
This will do..
now you can use this virtual env specifically for the package which requires a particular version of python