How do I use different Python version in venv from standard library? (Not virtualenv!)

On Linux/Mac you can easily install multiple versions of Python next to the main one and you can use the venv package from the standard library to create virtual environments from each version >= 3.3.

Create venv

$ python3.3 -m venv myvenv_foo  # Create a python3.4 venv named 'myvenv_foo'$ python3.4 -m venv myvenv_bar  # Create a python3.4 venv named 'myvenv_bar'$ python3.5 -m venv myvenv_baz  # Create a python3.5 venv named 'myvenv_baz'# etc...

Activate venv

source myvenv_foo/bin/activate  # Activates venv 'myvenv_foo'

Deactivate venv

deactivate

Notice: python vs pythonX.X

If you have multiple Python versions installed, you can access each one by adding the version num to the command e.g. python3.5, python3.6, etc. But keep in mind that when you activate a venv, you bind it to the clean/versionless python command, for as long as it's activated. E.g:

$ python -V # Use the *clean* 'python' command to show the main version of the OS.Python 2.7.6 $ python3.5 -m venv myvenv_foo # Create a new venv from 'python3.5'.$ source myvenv_foo/bin/activate # Activate venv.$ python -V # The *clean* 'python' command is now bound to your activated venv.Python 3.5.2 $ deactivate  # Deactivate venv.$ python -V  # Now the *clean* command is bound back to the main version.Python 2.7.6 

Note

I suggest using Pipenv to create/handle virutal environments over the venv package.

From the offical docs:

Managing multiple virtual environments directly can become tedious, so the dependency management tutorial introduces a higher level tool, Pipenv, that automatically manages a separate virtual environment for each project and application that you work on.

This is a very good question as there are several python modules / libraries (built-in & third party) with similar names and purposes. Can completely sympathise with OP's confusion.

There are really two different behaviours / responsibilities:

1). The ability to switch between different versions of (System) Python Interpreter eg. 2.7.10 or 3.5.0 etc

2). The ability to create virtual environments (which is just a local folder containing all the plumbing (binaries and libs) for a particular version of python. Can sort of think of this as a frozen local instance of a particular python version. Essentially it is a self-contained, light-weight python installation.

A module like pyvenv provides 2) above. It will allow you to create a virtual environment that is set at the version of Python that was used to create it.

$ python --versionPython 3.5.0$ pyvenv myenv   # myenv is now a local environment using Python 3.5.0

For further infoormation on pyvenv, see library/venv

A module like pyenv (the names are confusing, right? Notice, pyenv, and not pyvenv) on the other hand, controls which VERSION of python your system is basically running. This provides 1) above. So, when not running a particular virtual env via pyvenv etc, this is the "global" version in use. In fact, it is slightly more convoluted than that (as you can also setup local configuration etc), but essentially that is enough for this discussion.

For further information on pyenv see github.com/yyuu/pyenv

Suppose I want to run Python versions 2.7.10 and 3.5.0, then I would use pyenv to install these two versions (here, I chose as globals), and can view this using:

$ pyenv versions  system* 2.7.10 (set by ~/.pyenv/version)* 3.5.0 (set by ~/.pyenv/version)$ python --versionPython 3.5.0$ which python~/.pyenv/shims/python$ python2.7 --versionPython 2.7.10

Yes, there are several prominant alternatives to each of the above referenced modules / libs. Heated discussions on Reddit / SOF etc detailing and arguing which is best. Many of them do very similar things...

It's simply impossible. To create a Python venv of a specific Python version, we need this specific version.

Obviously, a Python interpreter doesn't "include" all the previous versions with their behavior. Python 3.4.1 cannot contain Python 2.7.8 executable anywhere inside.