I'm concerned seeing ".virtualenvs" hardcoded in, as it's not even standard with current virtualenvwrapper, and potentially steps on a user's WORKON_HOME environment (which is used to form PYTHON_DIR, at the top of this script).

[a bit of a side discussion here:] As for virtualenvwrapper vs. virtualenv, virtualenv-like behavior is part of python3.3+;  for python2.7, all that's really needed to use virtualenv is a little command symmetry.  I achieve it with a shell function to complement "deactivate":
activate () 
{ 
    source "$*"/bin/activate
}

which makes it nice to have my (let's say)  edx_all visibly contain something like Epy3,  Epy2 - a good reminder of what to develop for, test on. (you can tell I'm not a fan of "hidden," out-of-context virtual environments).