Martin Aspeli wrote: > 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 fix is totally scalable and completely correct. Chameleon.zpt just does not have any (real) ZCML anymore. Any package that has ZCML is, by definition, written for some framework as stuff that is meant to be overridden, otherwise it wouldn't be written as configuration. ZCML is unlike code in this way. If it wasn't meant to be overridden, it would be in code. All packages which are meant to be maximally useful outside the scope of that framework should be split into two things: the library portion, then some portion that contains ZCML for gluing in to some framework that wants ZCML in some specific configuration. So currently a glue package (five.pt) contains the ZCML that makes Chameleon work under Plone. All we did was remove the ZCML from chameleon.zpt itself and make some other package responsible for configuring the CA components used by chameleon.zpt. Frameworks that don't use ZCML don't even need to do this; they just import stuff. > 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. How is the current situation where chameleon.zpt just has no ZCML not 100% exactly the right thing? And again, why can't Plone and Zope 2 just use repoze.zcml in reality? Why would this not work? I just don't understand. >>> 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. How could it have? The only difference was that the package stopped including the two ZCML utility declarations and you had to configure them independently. That was hard? What promises could possibly have been made to Plone that those declarations would exist exactly in the place they were previously until the end of time? If working around that particular problem was at all hard, or caused any pain, we've got huge problems because people *completely* misunderstand the purpose of ZCML and configuration in general. > 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. Sounds pretty handwavy. I am particularly suspect of these practical reasons; they just don't need to exist. I suspect my only crime here is that I didn't do it "the way its done" (nicely, with lots of maillist chatter, over the course of weeks); if I had, the outcome would have been the same: a package that offered ZCML component registration handlers that doesn't rely on zope.security. It might have been named "zope.foo" rather than "repoze.foo". But the outcome would have been exactly the same. There is no way to change zope.component and get both b/w compat and no dependence on zope.security. This is still true. Note that there's some misguided idea that repoze.zcml has "magic" in it for dealing with multiregistries and WSGI or somesuch; this is not true. It knows nothing of either; all it does is implement "utility", "adapter", and the "subscriber" directives without security-related attributes. > By forking > without attempting to solve the problem at the framework level, the > chance for collaboration and shared effort is lost. There is no loss here. At very worst, if folks are unwilling to actually just *use* the package, there is a blueprint for some merge into zope.component that does not require security stuff. Once there's enough political will to actually *do* the merge, and tell the people who want the security stuff that they'll need to lose (or at least change code), putting the code in is cutnpaste. I fail to see how this is any sort of problem at all. - C _______________________________________________ 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 )