It's for both libraries and different versions of Python. This is common and trivial. I install specific versions of Python using the Deadsnakes PPA since I can easily pull in any version going back to 2.3 if I need. Or you can compile and install from source.

Then create a folder for your project, 'virtualenv -p /usr/bin/python3.5 venv' to create the venv in that directory. Activate/deactivate the environment as you wish when you want go between the system Python environment and the one in your folder.

I replied to @mrits because @mrits was presenting virtualenv as replacement for using pyinstaller to manage the installation of non-OS-managed Python versions (which @cowsandmilk was talking about).

I'm unsure how what I said:

> If you want another Python, then you need to install it yourself (somehow) and then point virtualenv at it.

Differs from what you are saying:

> 'virtualenv -p /usr/bin/python3.5 venv'

You can include the python interpreter inside the virtualenv. It's not entirely painfree (python and any pip packages are normally dynamically linked), but it works reasonably enough, especially when deploying it on the same OS version.

By default virtualenv links to the Python interpreter that you point it at (when you create your virtualenv). I'm unsure what method you would use to include the Python interpreter install in the virtualenv directory (other than creating a normal virtualenv, and then copying the files in after the fact).

virtualenv --always-copy

I sometimes wonder if it's possible to use a gobo-linux style system, whereby the package manager just downloads the package to a versioned folder, possibly expanding it out, to a a package cache - then the venv need only symlink to it. The same could be done for python installs. Then do the same for the system python (e.g /bin/python points to /someplace/pyjunk/system/python, which in turn is a symlink to a particular interpreter, e.g. /someplace/pyjunk/interpreters/py2/2.7/cython_2.7_blub-i386/python).