[Distutils] buildout and mod_wsgi
Jim Fulton
jim at zope.com
Tue Apr 29 14:28:31 CEST 2008
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.
> 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?
> 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
> 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.
> Does one of these exist already? Is there a better way?
2 is the better way.
Jim
--
Jim Fulton
Zope Corporation
More information about the Distutils-SIG
mailing list