How to leave/exit/deactivate a Python virtualenv

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

<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="325f57725f4b5f53515a5b5c57">[email protected]</a>:~$ workon env1
(env1)<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="eb868eab8692868a888382858e">[email protected]</a>:~$ workon env2
(env2)<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="7a171f3a1703171b191213141f">[email protected]</a>:~$ workon env1
(env1)<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="15787055786c7874767d7c7b70">[email protected]</a>:~$

How do I exit all virtual environments and work on my system environment again? Right now, the only way I have of getting back to [email protected]:~$ 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?

Answers:

Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1

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

Method 2

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.

Method 3

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

alias workoff='deactivate'

It is easy to remember:

[<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="89ebe6ebfafdece0e7c9e1e6fafd">[email protected]</a> ~]$ workon django_project
(django_project)[<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="4b292429383f2e22250b2324383f">[email protected]</a> ~]$ workoff
[<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="3c5e535e4f485955527c54534f48">[email protected]</a> ~]$

Method 4

To activate a Python virtual environment:

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

To deactivate:

$deactivate

Method 5

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

conda deactivate

Neither deactivate nor source deactivate worked for me.

Method 6

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.

Method 7

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:

[<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="4f3a3c2a3d0f2c20223f3a3b2a3d">[email protected]</a> ~]$ echo $VIRTUAL_ENV
No virtualenv!

[<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="0c797f697e4c6f63617c7978697e">[email protected]</a> ~]$ bash --init-file PythonVenv/bin/activate

(PythonVenv) [<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="4b3e382e390b2824263b3e3f2e39">[email protected]</a> ~]$ echo $VIRTUAL_ENV
/home/user/PythonVenv

(PythonVenv) [<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="d2a7a1b7a092b1bdbfa2a7a6b7a0">[email protected]</a> ~]$ exit
exit

[<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="285d5b4d5a684b4745585d5c4d5a">[email protected]</a> ~]$ echo $VIRTUAL_ENV
No virtualenv!

Method 8

For my particular case, I go to to the working directory

CD /myworkingdirectory

Then I activate my env like this:

my-env/scripts/activate

From this same working folder (/myworkingdirectory) to deactivate, I tried this but it does nothing:

my-env/scripts/deactivate

This does work:

deactivate

Method 9

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

Method 10

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%se[0mn" "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.

Method 11

Running deactivate [name of your environment] is able to exit/deactivate from your python environment.

Example with python3.6 Windows 10:

PS C:UserskyrlonDesktop> py -m venv env1
PS C:UserskyrlonDesktop> .env1Scriptsactivate
(env1) PS C:UserskyrlonDesktop> deactivate env1
PS C:Usersklongwood3Desktop> py -m venv env1

Example with python3.9 on Linux Ubuntu 20.04 LTS Desktop:

<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="412a38332d2e2f01312270">[email protected]</a>:~$ python3 -m venv venv1
<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="acc7d5dec0c3c2ecdccf9d">[email protected]</a>:~$ source venv1/bin/activate
(venv1) <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="84effdf6e8ebeac4f4e7b5">[email protected]</a>:~$ deactivate venv1
<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="cfa4b6bda3a0a18fbfacfe">[email protected]</a>:~$

Method 12

I my case, I was able to activate virtual environment using env-namescriptsactivate and deactivate it using deactivate. However, after running update on my windows PC deactivate was no longer recognized as an internal or external command. What I used from that moment onward is env-namescriptsdeactivate and that solved the problem.

Method 13

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.

All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0