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
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 http://martinaspeli.net/plone-book
Repoze-dev mailing list