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
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
