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:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
