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-lo...
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@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org