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 

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.


Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See

Repoze-dev mailing list

Reply via email to