[Zope-dev] Re: Pluggins vs Application Definition

[Jim Fulton]

Philipp von Weitershausen wrote:
> Jim Fulton wrote:
> 
>>Some recent discussions on the distutils-sig mailing list have
>>helped me to understand some issues related to the ways we
>>extend the Zope application server.  Traditionally, in Zope 2,
>>you extended Zope by "dropping" product packages into a special
>>"Products" package.  This was very convenient in many ways, but
>>doesn't always provide enough control or visibiity to what's
>>going on.
>>
>>In Zope 3, we went with a more explicit installation mechanism,
>>in which people had to explicitly cause a package's ZCML files to be
>>loaded for it to be used.  We added a mechanism to make this easier,
>>by simply dropping a file into a special directory, package-includes,
>>so an installer wouldn't have to fool with pointy brackets.
>>
>>I've noticed that at Zope Corporation, for our customer projects,
>>we tend not to use package-includes. We prefer to explicitly include
>>packages we use directly oin our application ZCML files.  (As
>>applications,  may be composed of several layers, we may include
>>things at multiple levels.)
>>
>>In thinking about this, I realized that there are two different users
>>here with different concerns:
>>
>>- Application developers need to build an application.  They will
>>  generally want fairly tight control over what goes into the
>>  application.  For them, it's valuable to say in an explicit
>>  way what they want.
>>
>>- If the application is extensible, then application users
>>  will want to be able to extend the application by adding
>>  "pluggins".  If application users are not technically
>>  sophisticated, or, more importantly, not technically interested,
>>  they peobably would prefer to just drop something into a special
>>  directory and be done with it.
>>
>>In summary, I think we need *both* approaches, as they serve different
>>needs.
> 
> 
> I agree with all of the above, but fail to see what your implication is.

Mostly thinking out loud and to lazy to bother blogging. :)

Well, more than that.  I think it's helpful to identify user's goals
and problems to be solved rather than argue about solutions in isolation,
as is commonly done.

> I think we have all that now.

In Zope 3, we don't have anything like plugins.  Zope 2 does and, thanks
to *also* adopting ZCML *is* getting the best of both worlds, sort of.

In neither case, IMO, to we really *separately* consider the separate
needs of the application developer and the high-level user.

 > Sure, we're not dropping Zope 3 plug-ins
> into a special directory but really anywhere in PYTHONPATH. Whether that
> additional freedom makes it easier is debatable, but I'd say we're still
> burned from Zope 2 wrt fixed drop-in locations.

I'm not sure what you are saying here.  Did you mean to say
"burned from Zope 2"? (probably not)

> Frankly, I think something like "ez_install zope.reallycoolstuff" is
> even easier than manually dropping stuff. As for the package-includes
> slug, a simple ez_install-like tool could help there as well. I sketched
> it out once on a blog post:
> http://www.z3lab.org/sections/blogs/philipp-weitershausen/2006_01_11_mata-los-productos

I agree. In fact, on the distutils-sig mailing list, they are contemplating
a plugin mechanism strikingly similar to Zope 2's for applications
such as Chandler and I recommended a more explicit aproach, where plugins
should be added under explicit user control.

I think we need to consider both use cases and have stories (documentation,
tools, etc.) for both and when designing these, we should consider the separate
needs of the application developers and high-level users who don't
need or *want* the same level of control.

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