collective.recipe.modwsgi 1.0rc1

WSGI from buildout

Introduction

‘’collective.recipe.modwsgi’’ is a zc.buildout recipe which creates a paste.deploy entry point for mod_wsgi.

It is very simple to use. This is a minimal ‘’buildout.cfg’’ file which creates a WSGI script mod_python can use:

[buildout]
parts = mywsgiapp

[mywsgiapp]
recipe = collective.recipe.modwsgi
eggs = mywsgiapp
config-file = ${buildout:directory}/production.ini

This will create a small python script in parts/mywsgiapp called ‘’wsgi’’ which mod_python can load.

The apache configuration for this buildout looks like this::

WSGIScriptAlias /mysite /home/me/buildout/parts/mywsgiapp/wsgi

<Directory /home/me/buildout>
    Order deny,allow
    Allow from all
</Directory>

This recipe does not fully install packages, which means that console scripts will not be created. If you need console scripts you can add a second buildout part which uses zc.recipe.egg or repoze.recipe.egg to do a full install.

Changelog

1.0rc1 - June 30, 2008

• Update the generated wrapper to test if a path is already in sys.path before adding it. This prevents paths being duplicated in sys.path when mod_wsgi reloads the module. [wichert]

1.0b3 - June 23, 2008

• Do not make the recipe a subclass of zc.recipe.egg.Eggs but use a local instance to determine the working set. [wichert]

• Format the sys.path changes in the wrapper to make it more human readable. This is purely cosmetic to help with debugging. [wichert]

• Also recreate the wsgi wrapper file when updating a buildout part. This is needed to get get changes to versions in the working set (such as different version pins) reflected in the wrapper. [wichert]

1.0b2 - June 13, 2008

• Call the Eggs constructor as well: working_set() needs too many of the internal variables it sets for us to set them ourselves. This fixes the recipe breaking when using find-links in buildout. [wichert]

1.0b1 - June 13, 2008

• Initial release [wichert]