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 environments and work on my system environment 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
Answered 2023-09-20 20:29:59
virtualenvwrapper
and maybe Doug Hellmann would consider it! Note, for those who might read these comments later, that workon
is NOT a native virtualenv
command (which is what the original question is about) but a virtualenvwrapper
command! - anyone 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.
Answered 2023-09-20 20:29:59
deactivate
is a function that gets created when you source the activate
file. Your suggestion to do source deactivate
doesn't make sense at all, as there is no file named deactivate
- anyone 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 ~]$
Answered 2023-09-20 20:29:59
.bashrc
? - anyone ~/.bashrc
- anyone To activate a Python virtual environment:
$cd ~/python-venv/
$./bin/activate
To deactivate:
$deactivate
Answered 2023-09-20 20:29:59
$source activate
- anyone $cd /to/dir/i/want/my/virtualenv/installed
then $virtualenv name_i_want_for_it
then $. name_i_want_for_it/bin/activate
virtualenv still seems a bit off to me. Needs to be improved... - anyone Running deactivate [name of your environment]
is able to exit/deactivate from your python environment.
Example with python3.6 Windows 10 in PowerShell:
PS C:\Users\kyrlon\Desktop> py -m venv env1
PS C:\Users\kyrlon\Desktop> .\env1\Scripts\activate
(env1) PS C:\Users\kyrlon\Desktop> deactivate env1
PS C:\Users\kyrlon\Desktop> py -m venv env1
Example with python3.9 on Linux Ubuntu 20.04 LTS Desktop:
kyrlon@pc1:~$ python3 -m venv venv1
kyrlon@pc1:~$ source venv1/bin/activate
(venv1) kyrlon@pc1:~$ deactivate venv1
kyrlon@pc1:~$
Answered 2023-09-20 20:29:59
I found that when within a Miniconda3 environment I had to run:
conda deactivate
Neither deactivate
nor source deactivate
worked for me.
Answered 2023-09-20 20:29:59
deactivate
was for virtualenv
, and source deactivate
is for old conda on Linux. conda deactivate
is a good cross-platform way for conda envs (not virtualenvs) - anyone 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.
Answered 2023-09-20 20:29:59
workon
command, it works from any directory. - anyone deactivate
in a shell script without first sourcing the script that defines this function (in that case you will have that command not found... error) - anyone 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
Answered 2023-09-20 20:29:59
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 venv
s don't leave any residual changes behind:
$ bash --init-file PythonVenv/bin/activate
venv
. Your original bash
shell remains unmodified.$ exit
OR [CTRL]
+[D]
venv
is in, and drops you back to the original shell from before the activation script made any changes to the environment.[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!
Answered 2023-09-20 20:29:59
In MacOs ventura -
to activate -
sudo chmod -R 755 ./venv/bin
source venv/bin/activate
to deactivate -
deactivate
Answered 2023-09-20 20:29:59
$ conda deactivate
or
$ source deactivate
would work.
If it doesn't work, try deactivate [name of your environment]
instead.
Answered 2023-09-20 20:29:59
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
Answered 2023-09-20 20:29:59
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.
Answered 2023-09-20 20:29:59
I my case, I was able to activate virtual environment using env-name\scripts\activate
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-name\scripts\deactivate
and that solved the problem.
Answered 2023-09-20 20:29:59
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.
Answered 2023-09-20 20:29:59
If you don't know how to exit some python environment I would just run
bash --norc
as there is a risk you missed deleting that code for entering to some python environment, which something such as conda/mamba already installed into your .bashrc
The conda/mamba enters environments the same way you can run bash inside bash. Default installation forces base environment to be activated by default, which drives me crazy as it might break lot of things, to exit it you just type
mamba deactivate
But you can configure conda in a way that you activate it only when you use it. Then if you e.g. type
mamba activate env
(env)mamba activate base
(base)mamba activate base
(base)mamba activate xy
You will actually be in nested environment (xy)
and (xy) -deactivate-> (base) -deactivate-> (base) -deactivate-> (env) -deactivate-> no conda/mamba
.
So if you are in some environment, do not know how much nested it is and you want to get base environment, you can also use
mamba activate base
Answered 2023-09-20 20:29:59