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.