I\'m using virtualenv and the virtualenvwrapper. I can switch between virtualenv\'s just fine using the workon
command.
me@mymachine:~$ workon
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!
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.
Use deactivate
.
(my_env) user@user:~/my_env$ deactivate
user@user-Lenovo-E40-80:~/my_env$
Note, (my_env)
is gone.
Simply type the following command on the command line inside the virtual environment:
deactivate
I found that when within a Miniconda3 environment I had to run:
conda deactivate
Neither deactivate
nor source deactivate
worked for me.
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