Patching a bash function

You either could ceate a deactivate alias (if that is enough) which has higher priority than a function. In that you could run a command before, but is not easy to run after.

alias deactivate='before; deactivate'

Or simply (much better) create a function with a simpler name:

deact(){ [[ $somevar == true ]] && deactivate
         [[ $othervar == admin ]] && sudo deactivate
       }

Or anything you want to implement. Yes that will only run where defined. It is **not a replacement for the word deactivate nor it works for other users.

The only way to do that is to create an executable program called deactivate, but that has lower priority than aliases and functions. Both will need to be un-defined.

If your shell is bash,zsh or ksh93 you can take advantage of the typeset -f builtin, which shows the source of a function:

# usage patch_func funcname before after
function patch_func {
        typeset nl=$'\n' lb={ src=`typeset -f "$1"` before=$2 after=$3
        src="${src/$lb/$lb$nl    $before$nl}"
        src="${src%\}*}$nl    $after$nl}"
        eval "$src"
}

Example:

$ deactivate(){ echo -n "{$0}"; for i; do echo -n " {$i}"; done; echo; }
$ patch_func deactivate 'echo before' 'echo after'
$ typeset -f deactivate
deactivate ()
{
    echo before;
    echo -n "{$0}";
    for i in "$@";
    do
        echo -n " {$i}";
    done;
    echo;
    echo after
}

This is of course quite fragile.

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 myenv;
• mkvirtualenv myenv creates a new env myenv;
• 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
#!/bin/bash
# This hook is sourced after a new virtualenv is activated.

env=$(basename "$VIRTUAL_ENV")
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 reference: virtualenvwrapper docs.

For a complete list of hooks, refer to Per-User Customization.