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 _______________________________________________ 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 )