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.