Lately I was working on changing the deployment of our in-house python modules. Those modules are for in-house usage only. Our previous deployment is to put all modules into somewhere (ex, /gozilla/pylib) and set the global environment variable, PYTHONPATH point to it.
I am wondering if it is a good idea to make use of virtualenv for this kind of deployment? Or some other alternative ways to do that, especially making use of setup.py mechanism with possibility to do auto unit-test, doc-gen, …?
Update
For making use of PYTHONPATH, it works well except that we have to do our own copy-n-paste for deployment and there is no any support for unit-test, doc-gen, module-dependency…
For making use of virtualenv as deployment tool, other (stand-alone) python scripts are asked to enter virtual env mode by source …bin/activate or by manually invoke execfile(activate_this, dict(_file_=activate_this)) in the very beginning of their own script. Is it possible to prevent this kind of manually entering virtualenv mode by execfile for each Python scripts?
That’s what I get right now 😉 and I am looking for other suggested ways to do that.
Yes, it is a good idea, since you get all the advantages you already mentioned.
I can recommend using Paver (which makes setuptools decent to extend), and also integrates things like unit tests, Sphinx, etc. into the build process.
Regarding the auto-activation of the venv, if you add “console_scripts” entry points to your project’s setup, then setuptools will automatically create script stubs that do just that — on any supported target platform.
Then you can either write an installer script that creates a virtualenv on the target machine using pre-built eggs, or package a whole venv into an OS package (e.g. .deb). There’s tools for that, too, in various stages of maturity.
*) http://paver.github.com/paver/