[Distutils] buildout and mod_wsgi

[Martin Aspeli]

Jim Fulton wrote:
> On Apr 28, 2008, at 8:00 PM, Martin Aspeli wrote:
> ...
>> I'm trying to deploy a Repoze-based application via mod_wsgi. I'm  
>> building Repoze in a buildout. The problem is that I need to get  
>> mod_wsgi to execute the WSGI script with buildout's working set of  
>> eggs.
>>
>> The mod_wsgi configuration looks like this:
>>
>>      WSGIDaemonProcess tmp threads=1 processes=4 maximum- 
>> requests=10000 python-path=/usr/lib/python2.4/site-packages
>>
>>      <VirtualHost *:80>
>>        ServerName my.machine.local
>>        WSGIScriptAlias / /path/to/bin/zope2.wsgi
>>        WSGIProcessGroup tmp
>>        WSGIPassAuthorization On
>>      </VirtualHost>
>>
>>
>> Now, this says to create a process pool of Python processes with the  
>> given python-path. This is really geared towards the virtualenv use  
>> case, where you'd have a custom virtualenv python-path for each  
>> project.
> 
>> In the case of buildout, however, the pythonpath is explicitly for  
>> console scripts by munging console scripts and doing sys.path  
>> manipulation.
> 
> This is imprecise at best. Buildout, like easy_install, generate  
> console scripts.  They do so with different assumptions.  Easy_install  
> makes the assumption that eggs are in the Python path, typically in  
> site-packages, wheres buildout doesn't.

It wasn't meant as a criticism at all - in general, I prefer this way of 
working. It's just made things a bit complex in this particular case. :)

>> Unfortunately, zope2.wsgi is not a console script, it's just a  
>> script that contains:
>>
>>  from paste.deploy import loadapp
>>
>>  ini = '/path/to/pasteconfig.ini'
>>  application = loadapp('config:%s' % ini)
>>
>> The key here is that this is a script that needs to define a global  
>> variable 'application'.
> 
> Interesting. So is it execfiled? Imported?

Imported, I believe. I'm not an expert on wsgi or mod_wsgi.

See http://code.google.com/p/modwsgi/wiki/ConfigurationGuidelines

>> The only way I can make this work, is to paste a block of sys.path  
>> manipulation from a console script that buildout has had the  
>> opportunity to munge, but that's not exactly a stable solution.
>>
>>
>> I can see the following possible solutions:
>>
>> 1) Make a buildout recipe that creates a directory with a .pth file  
>> for all the eggs in the working set. This would then be able to  
>> serve as a python-path above.
> 
> Nah

Can you elaborate on why this is the "wrong" solution?

>> 2) Make a buildout recipe that generates the zope2.wsgi script as  
>> above, but also generates the sys.path munging.
> 
> Yes, that's the right solution.
> 
> This should be straightforward.  All you really need is the  
> working_set that you can get from calling documented APIs in the  
> zc.buildout.easy_install module. Then you can iterate over that  
> getting the distribution locations to add to the front of sys.path.

I find the idea of writing out Python code to a file fairly daunting and 
error-prone. It's obviously doable, but I'd be happier with some way of 
looping over the working set from within the zope2.wsgi script itself 
and adding it to sys.path.

Is there some clean way to "serialise" the working set and pull it out 
again in a different script?

Cheers,
Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book