Activate a python virtual environment using activate_this.py in a fabfile on Windows

Question

I have a Fabric task that needs to access the settings of my Django project.

On Windows, I'm unable to install Fabric into the project's virtualenv (issues with Paramiko + pycrypto deps). However, I am able to install Fabric in my system-wide site-packages, no problem.

I have installed Django into the project's virtualenv and I am able to use all the "> python manage.py" commands easily when I activate the virtualenv with the "VIRTUALENV\Scripts\activate.bat" script.

I have a fabric tasks file (fabfile.py) in my project that provides tasks for setup, test, deploy, etc. Some of the tasks in my fabfile need to access the settings of my django project through "from django.conf import settings".

Since the only usable Fabric install I have is in my system-wide site-packages, I need to activate the virtualenv within my fabfile so django becomes available. To do this, I use the "activate_this" module of the project's virtualenv in order to have access to the project settings and such. Using "print sys.path" before and after I execute activate_this.py, I can tell the python path changes to point to the virtualenv for the project. However, I still cannot import django.conf.settings.

I have been able to successfully do this on *nix (Ubuntu and CentOS) and in Cygwin. Do you use this setup/workflow on Windows? If so Can you help me figure out why this wont work on Windows or provide any tips and tricks to get around this issue?

Thanks and Cheers.

---

REF:

• http://virtualenv.openplans.org/#id9 | Using Virtualenv without bin/python

Local development environment:

• Python 2.5.4
• Virtualenv 1.4.6
• Fabric 0.9.0
• Pip 0.6.1
• Django 1.1.1
• Windows XP (SP3)

Answer 1

You will have to execute the activate this, from within the fab file. Altho' I have not tested it, I believe following should work:

activate_this = '/path/to/env/bin/activate_this.py'
execfile(activate_this, dict(__file__=activate_this))

Answer 2

After some digging, I found out that this is an issue with the activate_this.py script. In it's current state, virtualenv<=1.4.6, this script assumes that the path to the site-packages directory is the same for all platforms. However, the path to the site-packages directory differs between *nix like platforms and Windows.

In this case the activate_this.py script adds the *nix style path:

VIRTUALENV_BASE/lib/python2.5/site-packages/

to the python path instead of the Windows specific path:

VIRTUALENV_BASE\Lib\site-packages\

I have created an issue in the virtualenv issue tracker which outlines the problem and the solution. If you are interested, you may check on the issue here: http://bitbucket.org/ianb/virtualenv/issue/31/windows-activate_this-assumes-nix-path-to-site

Hopefully the fix will be made available in an upcomming release of virtualenv.

---

If you need a fix for this problem right now, and the virtualenv package has not yet been patched, you may "fix" your own activate_this.py as shown below.

Edit your VIRTUALENV\Scripts\activate_this.py file. Change the line (17 ?):

site_packages = os.path.join(base, 'lib', 'python%s' % sys.version[:3], 'site-packages')

to

if sys.platform == 'win32':
    site_packages = os.path.join(base, 'Lib', 'site-packages')
else:
    site_packages = os.path.join(base, 'lib', 'python%s' % sys.version[:3], 'site-packages')

With this in place, your activate_this.py script would first check which platform it is running on and then tailor the path to the site-packages directory to fit.

Enjoy!