[Python-Dev] proto-pep: plugin proposal (for unittest)

[Michael Foord]

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 at 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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100730/9e05c3c2/attachment-0001.html>