Issues

Issue #204 resolved

Moving WORKON_HOME produces error

Jon Black
created an issue

I installed virtualenwrapper and by mistake set WORKON_HOME to ~/virtualenvs (mistake: not hidden). I sourced my ~/.bashrc file, and then realised the mistake.

I tried fixing this by deleting the ~/virtualenv folder and changing my ~/.bashrc to have WORKON_HOME=~/.virtualenvs (with the period). The logic I had was: I've just destroyed the environment, so it must be recreated.

When I sourced my now changed ~/.bashrc, I get the following:

stevedore.extension error calling 'user_scripts': [Errno 2] No such file or directory: '/home/jon/virtualenvs/initialize'.

So in spite of changing WORKON_HOME and re-sourcing my .bashrc, virtualenvwrapper still looks for things in the old (now deleted) place.

I thought I could be extra smart and just pip uninstall everything. I uninstalled virtualenv, virtualenvwrapper, stevedore. I then reinstalled. Same problem.

In summary: 1. I expected that removing the changing the WORKON_HOME should have it recreated. 2. I expected that uninstalling everything would return my system to the state before it had been installed.

Comments (5)

  1. Jon Black reporter

    In the end I removed everything, commented out my (correct) .bashrc stuff, rebooted, installed again, and it worked. Not a nice experience having to reboot like that though. No idea what went wrong.

  2. Jon Black reporter
    # virtualenvwrapper
    export WORKON_HOME=~/.virtualenvs
    source /usr/local/bin/virtualenvwrapper.sh
    export PIP_VIRTUALENV_BASE=$WORKON_HOME
    export PIP_RESPECT_VIRTUALENV=true
    export PROJECT_HOME=~/Projects
    
  3. Doug Hellmann repo owner

    All of that looks OK. I would move the PROJECT_HOME setting to a point before sourcing virtualenvwrapper.sh, but right now that's not an absolute requirement.

    The action that fixed your environment was logging out of the shell, rather than rebooting or reinstalling. The variable that was causing a problem was VIRTUALENVWRAPPER_HOOK_DIR. It defaults to $WORKON_HOME, but can be overridden if you want to put the hooks in a directory on their own. As with other user-controllable variables, it is not modified if it is set when virtualenvwrapper.sh is sourced. After sourcing the file the first time, it was set. Changing WORKON_HOME by itself did not reset the other variable, so the hook loader was looking for scripts in the wrong place.

  4. phoikoi

    I noticed that there's a line in the bin/activate script that hardcodes the location of the virtualenv into the definition of the VIRTUAL_ENV environment variable; this must be changed if it's moved, otherwise things will break.

  5. Log in to comment