Although this answer does not directly apply to
virtualenv usage - how about using
virtualenvwrapper? It's basically
virtualenv on steroids, taking care of envs management. Once installed, you get a set of additional commands:
workon lists all available environments when called without arguments, and activates the env when called with env name as agument, for example
workon myenv activates the env
mkvirtualenv myenv creates a new env
rmvirtualenv myenv removes it.
But there's more -
virtualenvwrapper defines a set of useful hooks where you can implement your own logic for envs customization, for example:
premkvirtualenv is executed when an env is created, but not activated yet;
postmkvirtualenv is executed when an env is created and activated;
preactivate is executed when an env activation was triggered;
postactivate is executed when an env was activated;
predeactivate is executed when an env deactivation was triggered;
postdeactivate is executed when an env was deactivated;
and many more. For example, I have a
postmkvirtualenv hook that installs
ipython in a new env:
$ cat $VIRTUALENVWRAPPER_HOOK_DIR/postmkvirtualenv
# This hook is sourced after a new virtualenv is activated.
logger -s -t "($env)" "installing ipython ..."
"$VIRTUAL_ENV/bin/pip" install ipython --quiet
To define additional logic for the env deactivation, you would thus have to write a custom bash script and place its contents to either
$VIRTUALENVWRAPPER_HOOK_DIR/predeactivate (if you need to run your stuff while the env is still activated) or
$VIRTUALENVWRAPPER_HOOK_DIR/postdeactivate (if you need the env to be deactivated to run the custom code).
For a complete list of hooks, refer to Per-User Customization.