Enable global site packages in an existing virtualenv

| by jpic | python virtualenv
Nowadays, virtualenv uses --no-site-packages by default. This means that the created virtualenv will not access global site-packages modules ie. /usr/lib/python2.7/site-packages/. To enable global site-packages again, just remove this file:: your_env/lib/python2.7/no-global-site-packages.txt Why would you do that ? Some modules are complicated to install (xpyb) or take too much time to compile (pyqt). Using the distro packages can be pretty useful !

Automatic virtualenv activation

| by jpic | virtualenv python
This article proposes a proven standard which enables automatic virtualenv activation. Demonstration Before, I had to do something like: cd myproject source ../env/bin/activate Now I just do: cd myproject Virtualenv standard Say I have a project called projectX, you could expect to find it as such on my servers: /srv /projectX_prod /projectX_test /projectX_dev /projectX_dev_env -> the virtualenv /env -> symlink to projectX_dev_env /main -> the checkout of the python project As you can see, it is easy and consistent. Read More

Django, Pinax, virtualenv, setuptools, pip, easy_install and requirements.txt

| by jpic | django pinax python virtualenv best-practice
This article describes how to build project dependencies with virtualenv. It is appliable to Pinax. Pinax uses virtualenv by default. It lets the developer have a project-specific python directory, including binaries, packages etc … OpenSuse for example supplies very bad Pinax packages which allows the user to mess with his operating system. It is much better to isolate project dependencies from a project to another for more granular control of the maintenance cost; for example if a package upgrade breaks the user project. Read More
1 of 1