Mmmm... I didn't mean for this to get quite so emotional. :) Chris (and Agendaless) is of course free to do whatever he wants with BFG. And as I've shown many times, I'm very supportive of the great work coming out of the Repoze project.
However, if Repoze is aiming to bridge the gap between the mature Zope components and the WSGI-enabled world of other Python frameworks and tools, then we should at least debate when the pendulum swings further away from Zope. > Everybody wins. I'm not quite sure about this. Anyone who wants to use traditional Zope packages that are configured using the standard zope ZCML stuff in a BFG application now has to contend with two methods of configuration that look identical but for an xmlns line at the top of the ZCML file, but are implemented in different places. That sounds like a recipe for confusion (especially considering that there is a reasonable amount of documentation and doctests out there that refer to the "old" way). It also sounds really hard to debug if ever there's a conflict between the two types of handlers. > Repoze != BFG This is certainly true. However, we've seen that a desire to do something in BFG (prune dependencies by replacing a core Zope package with a homespun version with tighter dependency control) had a knock-on effect on transitive dependencies in the Repoze world, which in turn impacts other users of those packages. The change in Chameleon meant that Repoze lost a few dependencies it didn't need, and Plone gained a few (or at least one) it didn't need. This is what I meant about BFG becoming a monolith: not that it's not built from reusable packages, but rather that if you want to control the transitive dependencies like this, you're going to have to re-implement any part of zope.* or plone.* or other users of the traditional ZCML way of configuring the CA, with repoze.* equivalents that are not thus polluted. If you want to pull in, say, plone.supermodel (a "pure Zope 3" package that should be re-usable and may be useful to BFG if it ever wants to serialise Zope 3 schema interfaces to/from an XML representation) well, it uses zope:* ZCML directives. Are you going to fork plone.supermodel? Are you going to re-implement your own version? Are you going to advocate that it too moves to repoze.zcml? None of those options sound particularly attractive. I certainly feel for Chris when he says he's worried about stop energy in Zope 3 land. There's a fair amount of that. But things do get done, when there's a will. Jim is a huge advocate of untangling dependencies. As are the Grok people. As are the Plone people. Repoze and Grok are where the innovation in the Zope world is happening right now, so I think they have a license to push things through. Instead of repoze.zcml, perhaps we could have a branch of the relevant zope.* package? We could then merge that later. repoze.zcml is a symptom that an improvement is needed further down the stack. In the Plone world, we've learned the hard way that rolling your own to avoid having to push something deeper into the stack is a costly strategy in the long run. Paul should certainly know this. :) It may be that Repoze should take a bit more pain now, in the form of writing a proposal and putting up with some flak or politicking, to save having to maintain a growing amount of custom code later. Or not. But at least let's not give up before we've tried. Cheers, Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
