repoze stack is comprised of the following software
repoze.bfgis a WSGI web framework inspired by Zope, Pylons, and Django. It uses Zope libraries to do much of its work.
repoze.obobis a stripped-down object publisher that acts as a WSGI application. It is responsible for:
- selecting the "root" object of the graph for a given request / URL;
- traversing from that root object along the "edges" defined by the URL path elements to find the "published object";
- invoking the published object to obtain the body;
- mapping response headers and body, along with the result from calling the published object, into appropriate WSGI output;
- serializing / encoding the response based on the type of the request (e.g., JSON / XML-RPC).
repoze.obob is currently more of a "publisher driver" than a publisher. Most of the actual work is done by "bob" modules which obob drives (repoze.zope2 is a "bob").
repoze.obobis used by
repoze.zope2, but is otherwise not being actively developed at this point.
repoze.zope2is a "bob" helper module that implements an analogue of the Zope 2 ZPublisher, with some major simplifications and cleanups. Its core mission is to allow publishing existing Zope2 applications in a WSGI environment that externalizes some of the features of "classic" Zope2 into middleware.
repoze.zope2is capable of publishing all known Zope applications, including applications which rely on WebDAV and XML-RPC, as well as all known Plone applications.
repoze.ploneis a meta-egg which depends on all Plone component eggs as well as repoze.zope2.
repoze.grokis a "bob" helper module that implements an analogue of the Zope 3 publication machinery in order to serve up Grok applications.
repoze.kissis a "bob" module which publishes content (files, images, templates) from the filesystem, using the
repoze.zope2helper. It runs this website.
repoze.mmwsgiis a WSGI wrapper that allows Mailman to be run simply under a WSGI server.
repoze.bitbltis a WSGI middleware component which automatically scales images according to the
heightproperty in an HTML img tag.
repoze.tm2is WSGI middleware that implements a transaction policy. It uses the
transactionmodule (shipped with ZODB) to commit or abort (if there is an exception) a transaction after each WSGI request.
Applications may register callbacks with
repoze.tm2(e.g., to close a connection, mainly). This behavior used to be hardcoded in Zope's publisher.
repoze.tm2is useful in any web application that requires transactions.
repoze.retryis WSGI middleware that retries a WSGI request some configurable number of times if any child application raises a ZODB ConflictError. This behavior used to be hardcoded in Zope's publisher. repoze.retry is currently only useful in the context of an application which uses ZODB.
TODO: investigate whether any useful RDBMS analogue exists (e.g., see the
repoze.vhmis WSGI middleware which normalizes specially-mangled URLs (or individual header values) into ordinary paths, with the additional information stored in the environment for use in generating dynamic URLs. It is an analogue / replacement for the Zope2 Virtual Host Monster.
repoze.errorlogimplements a WSGI middleware filter which intercepts exceptions and writes them to a Python
loggingmodule channel (or the
wsgi.errorsfilehandle, if no channel is configured). It also allows the browsing of limited exception history via a browser UI.
repoze.profileprovides a WSGI middleware component which aggregates Python profiling data across all requests to a WSGI application. It provides an HTML UI for viewing profiling data.
repoze.whois an identification and authentication framework for arbitrary WSGI applications. It acts as WSGI middleware. It is inspired by Zope 2's Pluggable Authentication Service (PAS) but it is not dependent on Zope in any way.
repoze.whatis an authorization framework for WSGI applications, based on
repoze.tempitais WSGI middleware egress filter which conditionally causes the body returned by the application to be run through the Tempita templating engine, using replacement values defined within the
repoze.tempitaPaste middleware configuration.
repoze.browseridis WSGI middleware loosely based on the Zope 2 concept of "browser ids", which are cookies which represent a browser, for use by sessioning libraries.
Library which manages ZODB databases and WSGI middleware which makes a ZODB connection available to downstream applications.
Declarative ACL-based security via middleware for WSGI applications. Not widely used.
Middleware which can help with in-production forensic debugging.
repoze.evolutionis a package which allows you to keep persistent data structures (data in a relational database, on the filesystem, in a persistent object store, etc) in sync with changes made to software. It does so by allowing you to create and use a package full of monotonically named "evolve" scripts which modify the data; each script brings the data up to some standard of a software version.
An indexing and searching system based on
A sessioning system (server side state for web applications) based on ZODB.
The ``repoze.formapi`` provides a form library which integrates with HTML forms instead of abstracting them away. It provides a small framework to take you through the entire process of rendering a form, provide default values, validate and execute form actions.
repoze.montyis a library that, given a WSGI environment dictionary (and a
wsgi.inputfile pointer if the request is a POST request), will return a dictionary back containing "converted" form/query string elements. The form and query string elements contained in the request are converted into simple Python types when the form element names are decorated with special suffixes.
repoze.urispaceimplements the URISpace 1.0 spec, as proposed to the W3C by Akamai. Its aim is to provide an implementation of that language as a vehicle for asserting declarative metadata about a resource based on pattern matching against its URI.
zopelibis the entire set of Zope "software home" 'Products'-namespace packages packaged as a setuptools-compatible package. The script that allows for this is checked into Repoze's CVS repository . That script is meant to be dropped into a checkout of a Zope "software home" and run from there to repeatably package Zope 2 as an sdist or bdist.
cmflibis the Zope CMF packaged as a setuptools-compatible package. It includes all the Zope 'Products'-namespace packages that are present in the classic CMF distribution (Products.CMFActionIcons, Products.CMFCalendar, Products.CMFCore, Products.CMFDefault, Products.CMFTopic, Products.CMFUid, Products.DCWorkflow) save for one: it has a dependency on an independently release-managed distribution of Products.GenericSetup. It was generated by using a setup.py checked into a location which depends on externals in Zope Corporation's SVN repository
plonelibsis a setuptools-compatible repackaging of the packages that ship in Plone 3's "lib/python" directory.
ploneproductsis a setuptools-compatible repackaging of the 'Products'-namespace packages that ship in Plone 3.
It depends on separately released-managed distributions of Products.PluggableAuthService and Products.PluginRegistry.
PILis a repackaging of the Python Imaging Library as a setuptools-compatible package.
Buildout-related (zc.buildout recipes and configuration files)
- Buildouts for repoze.bfg
- Buildouts for repoze.zope2
- Buildouts for repoze.plone
repoze.recipe.eggis a fork of zc.recipe.egg , a zc.builout recipe. It does exactly what zc.recipe.egg does, except it also automatically installs scripts from dependent eggs. This software is deprecated.