On 30/07/2010 15:04, Barry Warsaw wrote:
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
though:
https://tarekziade.wordpress.com/2009/05/01/basic-plugin-system-using-abcs-
and-the-extensions-package/
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
issues:
* 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
namespace?
* 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
enabled?
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!
Whilst in principle I agree with you... the plugin requirements for
unittest(2) and disutils2 are very different. The biggest advantage of
using ABCs in Tarek's post is around interfaces - you can ensure that
registered plugins have the required interface.
unittest doesn't *have* a required interface for plugins, which may
optionally implement handlers for *any* of the unittest events and the
rest of the functionality (configuration and command line interface
integration) is provided by virtue of the subclassing.
Explicit registration over implicit registration by subclassing is an
interesting discussion, but I like the simplicity provided by just
subclassing.
unittest allows any namespace to provide a plugin but has no
discoverability built in to it. Users specify which plugins they want to
use (per project and per user), plugins are then activated by importing.
Framework authors can load whichever plugins they want - it is probable
that discoverability would be useful here.
Automatic discoverability, a-la setuptools entry points, is not without
its problems though. Tarek outlines some of these in a more recent blog
post:
https://tarekziade.wordpress.com/2010/07/25/plugins-system-thoughts-for-an-entry-points-replacement/
Again I think the *needs* of unittest and distutils are different, so I
wonder if a single system can usefully suit both our needs (let alone
universally support other systems). Definitely an area worth exploring
though.
Michael
-Barry
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of your
employer, to release me from all obligations and waivers arising from any and all
NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use policies ("BOGUS
AGREEMENTS") that I have entered into with your employer, its partners, licensors,
agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges.
You further represent that you have the authority to release me from any BOGUS AGREEMENTS
on behalf of your employer.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
