I looked up a question on stackoverflow, and even found it. But it had no answer, so I wrote one.

With luck, it’s not too far wrong.

… well I guess I answered the wrong question. Oops.

Can an existing folder be redeclared a virtual enviroment with VirtualEnvWrapper?

I thought this was a project that had been made with virtualenv, and they wanted to put it under virtualenvwrapper. But apparently it was made with virtualenvwrapper, and I don’t know what they want to do with it.

They can probably get the answer to their question from my answer, though.

My answer:

Yes.

Anatomy of virtualenvwrapper

The existing project has two parts:

  • the virtualenv, where python and the python libs are installed, and
  • the project directory where your code is (that uses the virtualenv).

Virtualenvwrapper adds a third part, the virtualenvwrapper hooks. These are mainly shell functions that are called at certain times in a project or virtualenvs life cycle. They live in a third directory — by default, they are installed to ~/.virtualenvs (at least that was true on my Debian wheezy system). The hooks include postactivate, which we will edit below, and a bunch of others such as premkproject, premkvirtualenv, etc. The following list of keywords gives you the flavour of the hooks: initialize, pre/post, mk/rm, project/virtualenv, activate/deactivate. virtualenvwrapper puts these scripts in $VIRTUALENVWRAPPER_HOOK_DIR, which defaults to $WORKON_HOME.

virtualenvwrapper assumes

  • all the virtualenvs are in one place ($WORKON_HOME) (defaults to ~/.virtualenvs) Let’s say you have two virtualenvs, one called MYVENV and the other called MYOTHERVENV
  • all the project directories are in another place ($PROJECT_HOME).

Let’s say you have a project “is” in directory /home/me/where/my/proj that uses virtualenv MYVENV.

how to use workon to work on your pre-existing code and virtualenv

Here I’m assuming all your virtualenvs are in one place (in my case, they are all in /usr/local/virtualenv).

one-time operations

** edit ~/.virtualenvs/postactivate (+) to have

    case $env_name in
        MYVENV)
            cd /home/me/where/my/proj/is
            ;;
        MYOTHERVENV)
            cd /home/me/where/my/other/project/is2
            ;;
    esac

** links

    for hk in get_env_details initialize postactivate postdeactivate \
            postmkproject postmkvirtualenv postrmproject \
            postrmvirtualenv preactivate predeactivate premkproject \
            premkvirtualenv prermproject prermvirtualenv; do \
        ln -s ~/.virtualenvs/$hk /usr/local/pythonenv/$hk; \
    done

any time you want to work on your project that uses MYVENV virtualenv

    WORKON_HOME=/usr/local/pythonenv workon MYVENV

Of course if all your virtualenvs are indeed in the same place, you can define WORKON_HOME in your .profile and you won’t have to specify it on the command line every time.