On Jul 30, 2010, at 11:38 AM, Michael Foord wrote:

>I'm going to read your blog entry on the topic to evaluate it properly

Very interesting.  For Mailman 3, I have YAPS (yet another plugin system)
based on zope.interface and setuptools.  Bazaar has its own plugin system
which is different still.  I bet there are as many plugin APIs as there are
Python frameworks. (And isn't everything a framework these days? :)

I'm glad to see discussion begin to focus on providing consolidation in the
world of plugins for Python frameworks, and to begin to refactor basic
functionality into common tools.  I'd love to see a blessed plugin API
promoted to the stdlib for Python 3.2.  I think it has to address a number of

* Registration - How do third party plugins declare themselves to exist, and
  be enabled?  Part of this seems to me to include interface declarations
  too.  Is installation of the plugin enough to register it?  How do end users
  enable and disable plugins that me be registered on their system?  How do
  plugins describe themselves (provide short and log descriptions, declare
  options, hook into command line interfaces, etc.)?

* Installation - How are plugins installed on the system?  Do they have to
  appear in a special directory on the file system?  Do they need special
  setup.py magic to write extra files?  Do they need to live in a pre-defined

* Discoverability - How do frameworks discover all the plugins that are
  available?  Which available plugins claim to support a particular
  plugin-point?  How to do strict type checking on plugins?  Which plugins are

I'm sure there are more.  As always, I'd like to see simple APIs on both sides
that cover the common 80%.  Both Tarek's and Michael's posts and proto-peps
are great starts.  You guys should definitely write up a plugin PEP!


Attachment: signature.asc
Description: PGP signature

Python-Dev mailing list

Reply via email to