[Distutils] API for finding plugins

[Jim Fulton]

Phillip J. Eby wrote:
> At 07:15 AM 2/9/2006 -0500, Jim Fulton wrote:
> 
>> Phillip J. Eby wrote:
>>
>>> I recently started work on adding egg support to Chandler ( 
>>> http://chandler.osafoundation.org/ ), and ran into some interesting 
>>> issues with respect to plugin discovery.  Specifically, it's not easy 
>>> to do it well with the APIs that pkg_resources currently offers.  I 
>>> suspect that others who've worked on plugin loading for application 
>>> environments like Zope and Trac have probably run into similar issues.
>>> I'm proposing, therefore, to add a new API to pkg_resources to make 
>>> plugin-finding easier.  Among the requirements:
>>
>>
>> I don't fully understand the goal here.  From later discussion, I think
>> you envision a model where people drop eggs into some directory and an
>> application should be able to analyze this directory to determine
>> which ones to use, meaning which to include in some working set.
>> In addition to automatically determining the working
>> set, the application should be able to find the entry points in that
>> working set.
>>
>> Does that capture what you want to do?
> 
> 
> Yes, similar to the Zope 2 Basket product or Trac's plugin facility. 

OK, well I'll share the following intuition.  I think it's important to
distinguish, as I think you have, between application construction
and pluggins.  (I think Zope 2 blurred these too much.)  I think these
activities are performed by different people with different concerns.
I think the people who install plugins are idiots, in the best sense of
the word. :)  Meaning people who are not technically savy or
not technically interested.  Therefore, I think plugins should be
as simple as possible, providing well constrained functionality.
As mentioned elsewhere, I think, pluggin installation should be
an explicit operation under the control of the application. (This
is not what Zope 2 does, btw.)

 > It
> also relates to non-entrypoint metadata, like the resource system that 
> Ian and I have been discussing.  The goal there is to allow the located 
> plugin eggs to offer translations, localizations, skins, etc. for other 
> eggs to use.  I expect this will be relevant to Zope also, so I'd 
> appreciate your input there as well.  I've been away from Zope 3 a 
> little too long to know whether the ideas we're discussing can be made 
> to work for it as well.

I've read the thread a couple of times and am not entirely clear what your
use cases are.  I think it's all a bit too abstract for me.  I suspect
that Zope's component architecture is close to what you might want
for a "plugin registry".  It is serving our needs in this area very
well.  A package advertises the faclities it provides through
xml configuration files (ZCML).   People installing a package elect whether
to use the package configuration, or provide their own.  Often, they do
both, since ZCML supports overriding.  This system is far from perfect
and continues to evolve.  We do have a lot of valuable experience in
this area though.

This sounds like a good topic for an Open Space discussion at PyCon.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org