Update (2010-12): we (the CKAN project) have implemented an plugin/extension system for our pylons based web application – detailed documentation. We are looking to backport this work into pylons. If you are interested please get in touch (see ckan.org).

Purpose

Providing a plugin/extension framework for Pylons to support the reuse of common extensions

Work would be done in 2 distinct but related areas:

1. Design a simple plugin architecture for Pylons to support better extensibility
2. Document existing best practice for existing methods of extending pylons

Motivation

There are some standard components which it would be nice to be able to "plugin" in a standard way – e.g. users + auth, admin, settings, comments (more examples plus details below).

In many other frameworks/platforms (including e.g. Django) you do indeed see some
sort of plugin frameworks in which this sort of functionality does indeed become a plugin of some kind.

Pylons is of course different and more flexible compared to e.g. django. And that this architecture may mitigate against providing any standard "plugin" (e.g. how do we know which template framework – mako, genshi, jinja, etc – a given
pylons user is using ...).

However, I think it is still possible to do something useful along
these lines – even if a formal plugin framework isn't possible/required just "packaging" up best-practice(s) pattern for how to do standard stuff it would be very valuable (especially if a pattern kept up to date!).

Below are a list of some examples of the sorts of things that could be "plugins".

1. Users and Authentication - basic plugin to do users and

authentication out of the box

• Openid + Form (email confirmation etc)
• Build on existing plugins (repoze.who, authkit, whatever)
• Tie in to existing model (sqlalchemy) object (or provide demo code to create it)
• Even if just a demo that works it would be useful
• We've now done this ~ 6 times. There are commonalities and even if this were just a demo it would be useful

Admin - lightweight admin system

1. Model CRUD - provided an existing solution nicely wrapped up or
just document how to do it and ensure it really works – we've used
FormAlchemy plenty (and other options) but ensuring something "just
worked" would be useful
2. Settings module - think wordpress settings/options system

• DB Table + web user interface
• Config in db rather than ini file

Mini-CMS

• Simple content management - post/page table plus editor
• Slave CMS - pull content from an RSS feed from e.g. wordpress or other CMS
• We implemented this ourselves in http://openshakespeare.org

4. Commenting

• Commenting is a common functionality across many applications
• A basic plugin that providing commenting functionality either
  directly or pased on an existing pluggable service (e.g. disqus) would
  be extremely useful

Existing Work

1. Zope Component Architecture http://pypi.python.org/pypi/grokcore.component
2. Trac Component Architecture http://trac.edgewall.org/wiki/TracDev/ComponentArchitecture
3. Envisage (enthough): https://svn.enthought.com/enthought/wiki/EnvisageThree/core.html
4. http://pypi.python.org/pypi/pyutilib.component.core/ - Based on trac.core. Looks well-factored and very promising
5. http://flask.pocoo.org/extensions/

Background

Original thread