I’m using virtualenv and the virtualenvwrapper. I can switch between virtualenv’s just fine using the workon command.

me@mymachine:~$ workon env1
(env1)me@mymachine:~$ workon env2
(env2)me@mymachine:~$ workon env1
(env1)me@mymachine:~$ 

How do I exit all virtual machines and work on my real machine again? Right now, the only way I have of getting back to me@mymachine:~$ is to exit the shell and start a new one. That’s kind of annoying. Is there a command to work on “nothing”, and if so, what is it? If such a command does not exist, how would I go about creating it?

Usually, activating a virtualenv gives you a shell function named:

$ deactivate

which puts things back to normal.

I have just looked specifically again at the code for virtualenvwrapper, and, yes, it too supports deactivate as the way to escape from all virtualenvs.

If you are trying to leave an Anaconda environment, the command depends upon your version of conda. Recent versions (like 4.6) install a conda function directly in your shell, in which case you run:

conda deactivate

Older conda versions instead implement deactivation using a stand-alone script:

source deactivate

I defined an alias, workoff, as the opposite of workon:

alias workoff='deactivate'

It is easy to remember:

[bobstein@host ~]$ workon django_project
(django_project)[bobstein@host ~]$ workoff
[bobstein@host ~]$

Use:

$ deactivate 

If this doesn’t work, try

$ source deactivate

Anyone who knows how Bash source works will think that’s odd, but some wrappers/workflows around virtualenv implement it as a complement/counterpart to source activate. Your mileage may vary.

To activate a Python virtual environment:

$cd ~/python-venv/
$./bin/activate

To deactivate:

$deactivate

I found that when within a Miniconda3 environment I had to run:

conda deactivate

Neither deactivate nor source deactivate worked for me.

You can use virtualenvwrapper in order to ease the way you work with virtualenv.

Installing virtualenvwrapper:

pip install virtualenvwrapper

If you are using a standard shell, open your ~/.bashrc or ~/.zshrc if you use Oh My Zsh. Add these two lines:

export WORKON_HOME=$HOME/.virtualenvs
source /usr/local/bin/virtualenvwrapper.sh

To activate an existing virtualenv, use command workon:

$ workon myenv
(myenv)$

In order to deactivate your virtualenv:

(myenv)$ deactivate

Here is my tutorial, step by step on how to install virtualenv and virtualenvwrapper.

Since the deactivate function created by sourcing ~/bin/activate cannot be discovered by the usual means of looking for such a command in ~/bin, you may wish to create one that just executes the function deactivate.

The problem is that a script named deactivate containing a single command deactivate will cause an endless loop if accidentally executed while not in the venv. A common mistake.

This can be avoided by only executing deactivate if the function exists (i.e. has been created by sourcing activate).

#!/bin/bash

declare -Ff deactivate  && deactivate

Use deactivate.

(my_env) user@user:~/my_env$ deactivate
user@user-Lenovo-E40-80:~/my_env$ 

Note, (my_env) is gone.

I use zsh-autoenv which is based off autoenv.

zsh-autoenv automatically sources (known/whitelisted) .autoenv.zsh files, typically used in project root directories. It handles “enter” and leave” events, nesting, and stashing of variables (overwriting and restoring).

Here is an example:

; cd dtree 
Switching to virtual environment: Development tree utiles
;dtree(feature/task24|✓); cat .autoenv.zsh       
# Autoenv.
echo -n "Switching to virtual environment: "
printf "\e[38;5;93m%s\e[0m\n" "Development tree utiles"
workon dtree
# eof
dtree(feature/task24|✓); cat .autoenv_leave.zsh 
deactivate

So when I leave the dtree directory, the virtual environment is automatically exited.

"Development tree utiles" is just a name… No hidden mean linking to the Illuminati in here.

Using the deactivate feature provided by the venv’s activate script requires you to trust the deactivation function to be properly coded to cleanly reset all environment variables back to how they were before— taking into account not only the original activation, but also any switches, configuration, or other work you may have done in the meantime.

It’s probably fine, but it does introduce a new, non-zero risk of leaving your environment modified afterwards.

However, it’s not technically possible for a process to directly alter the environment variables of its parent, so we can use a separate sub-shell to be absolutely sure our venvs don’t leave any residual changes behind:

To activate:

$ bash --init-file PythonVenv/bin/activate

• This starts a new shell around the venv. Your original bash shell remains unmodified.

To deactivate:

$ exit OR [CTRL]+[D]

• This exits the entire shell the venv is in, and drops you back to the original shell from before the activation script made any changes to the environment.

Example:

[user@computer ~]$ echo $VIRTUAL_ENV
No virtualenv!

[user@computer ~]$ bash --init-file PythonVenv/bin/activate

(PythonVenv) [user@computer ~]$ echo $VIRTUAL_ENV
/home/user/PythonVenv

(PythonVenv) [user@computer ~]$ exit
exit

[user@computer ~]$ echo $VIRTUAL_ENV
No virtualenv!

I had the same problem while working on an installer script. I took a look at what the bin/activate_this.py did and reversed it.

Example:

#! /usr/bin/python
# -*- coding: utf-8 -*-
import os
import sys

# Path to virtualenv
venv_path = os.path.join('/home', 'sixdays', '.virtualenvs', 'test32')

# Save old values
old_os_path = os.environ['PATH']
old_sys_path = list(sys.path)
old_sys_prefix = sys.prefix


def deactivate():
    # Change back by setting values to starting values
    os.environ['PATH'] = old_os_path
    sys.prefix = old_sys_prefix
    sys.path[:0] = old_sys_path


# Activate the virtualenvironment
activate_this = os.path.join(venv_path, 'bin/activate_this.py')
execfile(activate_this, dict(__file__=activate_this))


# Print list of pip packages for virtualenv for example purpose
import pip
print str(pip.get_installed_distributions())

# Unload pip module
del pip

# Deactivate/switch back to initial interpreter
deactivate()

# Print list of initial environment pip packages for example purpose
import pip
print str(pip.get_installed_distributions())

I am not 100% sure if it works as intended. I may have missed something completely.

I have a Debian system currently running with python 2.5.4. I got virtualenv properly installed, everything is working fine. Is there a possibility that I can use a virtualenv with a different version of Python?

I compiled Python 2.6.2 and would like to use it with some virtualenv. Is it enough to overwrite the binary file? Or do I have to change something in respect to the libraries?

Just use the --python (or short -p) option when creating your virtualenv instance to specify the Python executable you want to use, e.g.:

virtualenv --python=/usr/bin/python2.6 <path/to/new/virtualenv/>

N.B. For Python 3.3 or later, refer to The Aelfinn’s answer below.

Since Python 3, the Python Docs suggest creating the virtual environment with the following command:

python3 -m venv <myenvname>

Please note that venv does not permit creating virtual environments with other versions of Python. For that, install and use the virtualenv package.

Obsolete information

The pyvenv script can be used to create a virtual environment

pyvenv /path/to/new/virtual/environment

but it has been deprecated since Python 3.6.

These are the steps you can follow when you are on a shared hosting environment and need to install & compile Python from source and then create venv from your Python version. For Python 2.7.9. you would do something along these lines:

mkdir ~/src
wget http://www.python.org/ftp/python/2.7.9/Python-2.7.9.tgz
tar -zxvf Python-2.7.9.tgz
cd Python-2.7.9
mkdir ~/.localpython
./configure --prefix=$HOME/.localpython
make
make install

virtual env

cd ~/src
wget https://pypi.python.org/packages/5c/79/5dae7494b9f5ed061cff9a8ab8d6e1f02db352f3facf907d9eb614fb80e9/virtualenv-15.0.2.tar.gz#md5=0ed59863994daf1292827ffdbba80a63
tar -zxvf virtualenv-15.0.2.tar.gz
cd virtualenv-15.0.2/
~/.localpython/bin/python setup.py install
virtualenv ve -p $HOME/.localpython/bin/python2.7
source ve/bin/activate   

Naturally, this can be applicable to any situation where you want to replicate the exact environment you work and deploy on.

virtualenv --python=/usr/bin/python2.6 <path/to/myvirtualenv>

There is an easier way,

virtualenv venv --python=python2.7

Thanks to a comment, this only works if you have python2.7 installed at the system level (e.g. /usr/bin/python2.7).

Otherwise, if you are using homebrew you can use the path to give you what you want.

virtualenv venv --python=/usr/local/bin/python

You can find the path to your python installation with

which python

This will also work with python 3.

which python3
>> /usr/local/bin/python3
virtualenv venv --python=/usr/local/bin/python3

Ultimately condensing to:

virtualenv venv -p `which python`
virtualenv venv -p `which python3`

Under Windows for me this works:

virtualenv --python=c:\Python25\python.exe envname

without the python.exe I got WindowsError: [Error 5] Access is denied I have Python2.7.1 installed with virtualenv 1.6.1, and I wanted python 2.5.2.

Mac OSX 10.6.8 (Snow Leopard):

1) When you do pip install virtualenv, the pip command is associated with one of your python versions, and virtualenv gets installed into that version of python. You can do

 $ which pip   

to see what version of python that is. If you see something like:

 $ which pip
 /usr/local/bin/pip

then do:

$ ls -al /usr/local/bin/pip
lrwxrwxr-x  1 root  admin  65 Apr 10  2015 /usr/local/bin/pip ->
../../../Library/Frameworks/Python.framework/Versions/2.7/bin/pip

You can see the python version in the output.

By default, that will be the version of python that is used for any new environment you create. However, you can specify any version of python installed on your computer to use inside a new environment with the -p flag:

$ virtualenv -p python3.2 my_env  
Running virtualenv with interpreter /usr/local/bin/python3.2  
New python executable in my_env/bin/python  
Installing setuptools, pip...done.  

virtualenv my_env will create a folder in the current directory which will contain the Python executable files, and a copy of the pip [command] which you can use to install other packages.

http://docs.python-guide.org/en/latest/dev/virtualenvs/

virtualenv just copies python from a location on your computer into the newly created my_env/bin/ directory.

2) The system python is in /usr/bin, while the various python versions I installed were, by default, installed into:

 /usr/local/bin

3) The various pythons I installed have names like python2.7 or python3.2, and I can use those names rather than full paths.

========VIRTUALENVWRAPPER=========

1) I had some problems getting virtualenvwrapper to work. This is what I ended up putting in ~/.bash_profile:

export WORKON_HOME=$HOME/.virtualenvs
export PROJECT_HOME=$HOME/django_projects  #Not very important -- mkproject command uses this
#Added the following based on: 
#http://stackoverflow.com/questions/19665327/virtualenvwrapper-installation-snow-leopard-python
export VIRTUALENVWRAPPER_PYTHON=/usr/local/bin/python2.7 
#source /usr/local/bin/virtualenvwrapper.sh
source /Library/Frameworks/Python.framework/Versions/2.7/bin/virtualenvwrapper.sh

2) The -p option works differently with virtualenvwrapper: I have to specify the full path to the python interpreter to be used in the new environment(when I do not want to use the default python version):

$ mkvirtualenv -p /usr/local/bin/python3.2 my_env
Running virtualenv with interpreter /usr/local/bin/python3
New python executable in my_env/bin/python
Installing setuptools, pip...done.
Usage: source deactivate

removes the 'bin' directory of the environment activated with 'source
activate' from PATH. 

Unlike virtualenv, virtualenvwrapper will create the environment at the location specified by the $WORKON_HOME environment variable. That keeps all your environments in one place.

These two commands should work fine.

virtualenv -p python2 myenv (For python2)

virtualenv -p python3 myenv (For python3)

Suppose you currently have python 2.7 installed in your virtualenv. But want to make use of python3.2, You would have to update this with:

$ virtualenv --python=/usr/bin/python3.2 name_of_your_virtualenv

Then activate your virtualenv by:

$ source activate name_of_your_virtualenv

and then do: python --version in shell to check whether your version is now updated.

You can call virtualenv with python version you want. For example:

python3 -m virtualenv venv

Or alternatively directly point to your virtualenv path. e.g. for windows:

c:\Python34\Scripts\virtualenv.exe venv

And by running:

venv/bin/python

Python 3.5.1 (v3.5.1:37a07cee5969, Dec  5 2015, 21:12:44) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>

you can see the python version installed in virtual environment

The -p approach works well, but you do have to remember to use it every time. If your goal is to switch to a newer version of Python generally, that’s a pain and can also lead to mistakes.

Your other option is to set an environment variable that does the same thing as -p. Set this via your ~/.bashrc file or wherever you manage environment variables for your login sessions:

export VIRTUALENV_PYTHON=/path/to/desired/version

Then virtualenv will use that any time you don’t specify -p on the command line.

Even easier, by using command substitution to find python2 for you:

virtualenv -p $(which python2) <path/to/new/virtualenv/>

Or when using virtualenvwrapper :

mkvirtualenv -p $(which python2) <env_name>

For Mac(High Sierra), install the virtualenv on python3 and create a virtualenv for python2:

 $ python3 -m pip install virtualenv
 $ python3 -m virtualenv --python=python2 vp27
 $ source vp27/bin/activate
 (vp27)$ python --version
 Python 2.7.14

On the mac I use pyenv and virtualenvwrapper. I had to create a new virtualenv. You need homebrew which I’ll assume you’ve installed if you’re on a mac, but just for fun:

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"


brew install pyenv
pyenv install 2.7.10
pyenv global 2.7.10
export PATH=/Users/{USERNAME}/.pyenv/versions/2.7.10/bin:$PATH
mkvirtualenv -p ~/.pyenv/versions/2.7.10/bin/python  {virtual_env_name}

I also froze my requirements first so i could simply reinstall in the new virtualenv with:

pip install -r requirements.txt

[November 2019] I needed to install a Python 3.7 environment (env) on my Python 3.8-based Arch Linux system. Python 3.7 was no longer on the system, so I could not downgrade Python, to install a package that I needed.

Furthermore, I wanted to use that package / Python 3.7 inside a virtual environment (venv). This is how I did it.

Download Python version source files:

I downloaded the Python 3.7.4 source files from

https://www.python.org/downloads/source/

to

/mnt/Vancouver/apps/python_versions/src/Python-3.7.4.tgz

I then extracted that archive (source files) to

/mnt/Vancouver/apps/python_versions/src/Python-3.7.4/

Installation:

[Note: in my system env, not a venv.]

cd /mnt/Vancouver/apps/python_versions/src/Python-3.7.4/
time ./configure                 ## 17 sec
time make                        ## 1 min 51 sec
time sudo make install           ## 18 sec
time make clean                  ## 0.3 sec

Examine installed Python versions:

$ which python
/usr/bin/python

$ python --version
Python 3.8.0

$ which python3.7
/usr/local/bin/python3.7

$ python    ## Python 3.8 [system / env]
Python 3.8.0 (default, Oct 23 2019, 18:51:26) 
[GCC 9.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

$ python3.7    ## newly-installed Python 3.7 package
Python 3.7.4 (default, Nov 20 2019, 11:36:53) 
[GCC 9.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> print(sys.version)
3.7.4 (default, Nov 20 2019, 11:36:53) 
[GCC 9.2.0]
>>>

$ python3.7 --version                                                                                                 
Python 3.7.4

How to create a venv for a specific Python version:

https://docs.python.org/3/tutorial/venv.html

12.2. CREATING VIRTUAL ENVIRONMENTS

The module used to create and manage virtual environments is called venv. venv will usually install the most recent version of Python that you have available. If you have multiple versions of Python on your system, you can select a specific Python version by running python3 or whichever version you want.

To create a virtual environment, decide upon a directory where you want to place it, and run the venv module as a script with the directory path:

python3 -m venv tutorial-env

This will create the tutorial-env directory if it doesn’t exist, and also create directories inside it containing a copy of the Python interpreter, the standard library, and various supporting files. …

Create Python 3.7 venv [on a Python 3.8 operating env / system]:

python3.7 -m venv ~/venv/py3.7      ## create Python 3.7-based venv
source ~/venv/py3.7/bin/activate    ## activate that venv
deactivate                          ## deactivate that venv (when done, there)

Added to ~/.bashrc:

alias p37='echo "   [Python 3.7 venv (source ~/venv/py3.7/bin/activate)]" && source ~/venv/py3.7/bin/activate'

Test Python 3.7 venv:

$ p37                                                                                                                 
[Python 3.7 venv (source ~/venv/py3.7/bin/activate)]

(py3.7)$ python --version
Python 3.7.4

(py3.7)$ python
Python 3.7.4 (default, Nov 20 2019, 11:36:53) 
[GCC 9.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> print(sys.version)
3.7.4 (default, Nov 20 2019, 11:36:53) 
[GCC 9.2.0] 
>>>

In windows subsystem for linux:

1. Create environment for python3:

   virtualenv --python=/usr/bin/python3 env
   

2. Activate it:

   source env/bin/activate
   

On windows:

py -3.4x32 -m venv venv34

or

py -2.6.2 -m venv venv26

This uses the py launcher which will find the right python executable for you (assuming you have it installed).

Yes, the above answers are correct and works fine on Unix based systems like Linux & MAC OS X.

I tried to create virtualenv for Python2 & Python3 with the following commands.

Here I have used venv2 & venv3 as their names for Python2 & Python3 respectively.

Python2 »

MacBook-Pro-2:~ admin$ virtualenv venv2 --python=`which python2`
Running virtualenv with interpreter /usr/local/bin/python2
New python executable in /Users/admin/venv2/bin/python
Installing setuptools, pip, wheel...done.
MacBook-Pro-2:~ admin$ 
MacBook-Pro-2:~ admin$ ls venv2/bin/
activate        easy_install        pip2.7          python2.7
activate.csh        easy_install-2.7    python          wheel
activate.fish       pip         python-config
activate_this.py    pip2            python2
MacBook-Pro-2:~ admin$ 

Python3 »

MacBook-Pro-2:~ admin$ virtualenv venv3 --python=`which python3`
Running virtualenv with interpreter /usr/local/bin/python3
Using base prefix '/Library/Frameworks/Python.framework/Versions/3.6'
New python executable in /Users/admin/venv3/bin/python3
Also creating executable in /Users/admin/venv3/bin/python
Installing setuptools, pip, wheel...done.
MacBook-Pro-2:~ admin$ 
MacBook-Pro-2:~ admin$ ls venv3/bin/
activate        easy_install        pip3.6          python3.6
activate.csh        easy_install-3.6    python          wheel
activate.fish       pip         python-config
activate_this.py    pip3            python3
MacBook-Pro-2:~ admin$ 

Checking Python installation locations

MacBook-Pro-2:~ admin$ which python2
/usr/local/bin/python2
MacBook-Pro-2:~ admin$ 
MacBook-Pro-2:~ admin$ which python3
/usr/local/bin/python3
MacBook-Pro-2:~ admin$ 

It worked for me

sudo apt-get install python3-minimal

virtualenv --no-site-packages --distribute -p /usr/bin/python3 ~/.virtualenvs/py3

I use pyenv to manage my python version.

pyenv install 3.7.3
pyenv local 3.7.3

Check your python version:

$ python --version
Python 3.7.3

Create the virtual environment with venv:

python -m venv .

Then activate the Virtual Environment:

source bin/activate

Check your python version:

$ python --version
Python 3.7.3

You may need to remove the previous virtual environment

rm -rf bin

These seem a little overcomplicated for Windows. If you’re on Windows running python 3.3 or later, you can use the python launcher py to do this much more easily. Simply install the different python version, then run:

py -[my version] -m venv env

This will create a virtual environment called env in your current directory, using python [my version]. As an example:

py -3.7 -m venv env
./env/Scripts/activate

This creates a virtual environment called env using python3.7 and activates it. No paths or other complex stuff required.

virtualenv -p python3 myenv

Link to Creating virtualenv

For Debian (debian 9) Systems in 2019, I discovered a simple solution that may solve the problem from within the virtual environment.

Suppose the virtual environment were created via:

python3.7 -m venv myenv

but only has versions of python2 and python2.7, and you need the recent features of python3.7.

Then, simply running the command:

(myvenv) $ python3.7 -m venv --upgrade /home/username/path/to/myvenv/

will add python3.7 packages if they are already available on your system.

This was a bug with virtualenv. Just upgrading your pip should be the fix.

pip install --upgrade virtualenv

As already mentioned in multiple answers, using virtualenv is a clean solution. However a small pitfall that everyone should be aware of is that if an alias for python is set in bash_aliases like:

python=python3.6

this alias will also be used inside the virtual environment. So in this scenario running python -V inside the virtual env will always output 3.6 regardless of what interpreter is used to create the environment:

virtualenv venv --python=pythonX.X

It worked for me on windows with python 2 installation :

1. Step 1: Install python 3 version .
2. Step 2: create a env folder for the virtual environment.
3. Step 3 : c:\Python37\python -m venv c:\path\to\env.

This is how i created Python 3 virtual environment on my existing python 2 installation.

You can do it by doing this:

virtualenv -p python3 .

Yes you just need to install the other version of python, and define the location of your other version of python in your command like :

virtualenv /home/payroll/Documents/env -p /usr/bin/python3

Here is the stepbystep how to create the Virtual environment in Visual Studio Code folder: I used Powershell (Administrator mode):
1. I create a VSCode folder – “D:\Code_Python_VE” where I want to create Virtual environment.
2. Next I type the command – “pip3 install virtualenv”. (D:\Code_Python_VE> pip3 install virtualenv) 3. D:\Code_Python_VE> python3 -m venv project_env
4. D:\Code_Python_VE>project_env\Scripts\activate.bat
5. D:\Code_Python_VE> ls – This will list a new directory “project_env”.
6. D:\Code_Python_VE> code . This will start Visual Studio Code. Make sure the command is (code .).
7. Create launch.jason with following content:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "type": "python",
            "request": "launch",
            "name": "Python: Current File (Integrated Terminal 1)",
            "program": "${file}"
        },
        {
            "name": "Python: Current File (Integrated Terminal 2)",
            "type": "python",
            "request": "launch",
            "program": "${file}",
            "console": "integratedTerminal"
        }
    ]
}

(Please search how to go to Debug window and Add new Configuration in VS Code).

8. Press F1 in Visual studio code and the command pallet will open – Select Python Interpreter and select the virtual environment project_env.
9. Add test.py file with one statement print(“Hello World”).
10. Run this program.
11. In Visual studio Code terminal –
    (project_env) d:\Code_Python_VE>python -m pip install –upgrade
    I hope this helps.

UBUNTU 19.04 / Global Python 3.7.

This worked for me, enabling a Python 3.8 environment using the recommended venv for python 3 development.

Install 3.8 and 3.8 venv module

$ sudo apt install python3.8 python3.8-venv ## plus any other modules you need

Create your Virtual Env using the python version you want in that env

$ /usr/bin/python3.8 -m venv python38-env

switch into your virtual env

$ source python38-env/bin/activate

python -V = python 3.8