[Zope-dev] the Zope Framework project

[Martin Aspeli]

Chris McDonough wrote:

> Sorry, the "you" above in "you scolded" was Martin Aspeli, not Faassen.

Note that the "scolding" had something to do with you breaking Plone 
trunk due to a transitive change in Chameleon, and the realisation that 
from this point on, any package shared between repoze.bfg and Plone (or 
anything else) that is configured with ZCML, will probably need to be 
forked. We found a workaround with Chameleon, but not one that will scale.

The other cause for frustration was that you'd basically discounted all 
possibility of doing this at the zope.component level (and thus letting 
others benefit - Zope 2, Five and Plone needs rid of the zope.security 
dependency too) before you'd even tried. However, I didn't know then 
quite how disillusioned you were with Zope, or that you were quite so 
willing to maintain forks/spin-offs/re-implementations under the Repoze 
brand.

> I also mentioned "or anyone else" above; the point is just to reduce
> inappropriate dependencies.  Inappropriate dependencies still remain in
> zope.component's implementation of these ZCML directives.  These inappropriate
> dependencies are shed when you want ZCML and you use repoze.zcml.  Fine, Grok
> may not need it because it just doesn't care about ZCML at all; but other people
> who want to use ZCML without the other kitchen sinkness do.

I think you'd be hard pressed to find anyone on this list who disagrees 
with that statement. ;)

>> And you think it's all due to the brand...
> 
> Yes!  Someone who *wants* to use basic ZCML directives but doesn't want
> zope.security, zope.location, zope.publisher, zope.traversing, zope.i18n, and
> pytz can *already* use repoze.zcml; the only thing they don't get here is the brand.

At least when the change was made to Chameleon, it caused 
incompatibilities that basically broke another application using 
zope.component's versions of these directives. I'm sure those could be 
resolved (and were, with a workaround, in Chameleon), but it caused a 
fair bit of pain.

But more importantly, there are lots of people using Zope the platform, 
who have the same types of problems. For Zope 2 or Five or Plone to 
switch wholesale to repoze.zcml is probably going to be impossible, for 
documentation-related, practical and technical reasons. By forking 
without attempting to solve the problem at the framework level, the 
chance for collaboration and shared effort is lost.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book