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 venvs 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.zshfiles, 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