On Dec 22, 2008, at 6:36 AM, Martin Aspeli wrote:
> 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
> 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.
Repoze != BFG. Chris didn't change a single thing in Repoze itself.
>> Everybody wins.
> I'm not quite sure about this. Anyone who wants to use traditional
> packages that are configured using the standard zope ZCML stuff in a
> 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
> two types of handlers.
Some people want to use BFG but aren't after "fidelity to the Zope3
megaframework". These people should not pay a tax. Remember, Zope3
assumes a ZODB. BFG doesn't even include ZODB.
People whose goal includes using existing Zope3 packages have to do
some work. Sure, they'll get a different flavor of adapters, but that
makes sense: they behave differently! Chris explained this, and you
don't want to discuss this, so I'll conclude that this discussion is
meta and not technical.
People who want to use ToscaWidgets (like me) have to do some work,
too. That's part of the Zen of BFG: it leaves out a LOT. You only
pay for what you eat, and we don't want to pay for trusted adapters.
"Only pay for what you eat" isn't your goal. It's ok for new projects
to start up and tackle fresh ideas and go in new directions.
>> 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-
Please list the cases where BFG has forced an inappropriate change 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.
The change meant Chameleon lost dependencies and *huge swaths of side-
effect-ful, harmful* policy that it didn't need.
Chameleon doesn't exist solely for Plone, I believe. Chameleon users
are now the beneficiary of Chris's work to make a smaller, less side-
effect-ful Chameleon. This served Chameleon's purpose, which is to be
bigger than Plone/Zope. He also did extra work to make it easy to
sign up for the Zope assumptions.
Everybody wins, including non-Plone users. They count too. [wink]
> 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
> transitive dependencies like this, you're going to have to re-
Remember, each time you want to say "transitive dependencies", you
should replace it with the more accurate "harmful side-effects".
> any part of zope.* or plone.* or other users of the traditional ZCML
> of configuring the CA, with repoze.* equivalents that are not thus
True. But so what? Those packages presume a pile of assumptions that
shouldn't be shoved down the throat of every possible BFG user. BFG
doesn't provide the packages they assume, so they wouldn't work
anyway. It's up to the person whose goals include plone.supermodel to
sign up for the side effects.
I think your vision that any plone.* package should work in BFG is the
flaw here. That's not the vision of BFG. plone.* packages are
designed, I believe, for sharing with other packages atop the Zope3
BFG is not atop the Zope3 application server. Perhaps that part is
unclear. We're like most people: when it is convenient to grab
something, BFG will. If the pain is too high, then no. Rational
> 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
BFG would never, ever, never have a goal of "serialize Zope 3
schemas". It doesn't include Zope 3 schemas. It doesn't include the
*concept* of schemas!!
However, some BFG user might want plone.supermodel. Some Pylons user
might want plone.supermodel. In either case, the integration task
falls on the integrator, not the destination framework.
The integrator is responsible for including the packages that
supermodel wants, which includes Zope3-style trusted adapters.
> serialise Zope 3 schema interfaces to/from an XML representation)
> it uses zope:* ZCML directives. Are you going to fork
> 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.
No, the user is going to add a line to their package and be off the
the races. An eminently fair tradeoff.
Sure, it would be nicer if Zope 2, Zope 3, Grok, and Repoze could all
magically have the same needs. Sometimes they do, sometimes they
don't. When it is easy to share, they share. When it is hard to
share, the people that care a lot about that fix the underlying
I think, fundamentally, that's the issue. You want to sign Chris up
to fix Zope3. He wants to work on Repoze and BFG.
> 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
It has been explained to you that this is more than a mere packaging
discussion. Possibly you disagree, as you still paint it as
Thus, since you have the "will", and since Chris has already done the
"way", I recommend that you take repoze.zcml back to the Zope 3
community and get their read on it. Chris has scratched half of your
itch. Shouldn't you walk the walk and do your half?
> 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
repoze.zcml is a symptom that not everybody has the same needs.
Grok's configuration system wasn't incepted in the Zope 3 stack. It
was done under its own flag, and projects that wanted it, took upon
themselves to evaluate it and integrate it. Nobody demanded that the
Grok people do their reformation inside Zope3 itself.
I think that worked well for Grok. Sounds like what Chris is doing.
Repoze-dev mailing list