Paul Everitt wrote:
> 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  
>> 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.
> Repoze != BFG.  Chris didn't change a single thing in Repoze itself.

Mmm... Chameleon is not in the repoze.* namespace, but it's in the 
Repoze repository, so if that's the definition of "Repoze" then he did.

> 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.

It's absolutely about policy and roadmap, if that's what you mean by "meta".

>>> 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
> Please list the cases where BFG has forced an inappropriate change on  
> Repoze.

I think the fact that Chameleon now uses repoze.zcml may be. And my 
argument is that if you want to both use other parts of the Repoze stack 
that use the Zope 3 CA, and you want this minimal set of dependencies, 
then you're going to have to make the same change to all of those, which 
means that all other users of those packages have to live with the two 
ways of configuring components. That may be inappropriate. At least I 
think it deserves some serious consideration, not at least given how 
integration-oriented the Repoze stack tries to be.

> Everybody wins, including non-Plone users.  They count too. [wink]

My point is not specific to Plone, even though that's obviously where 
I'm coming from. Anyone who wants to use existing Zope packages with BFG 
or Chameleon now have two means of configuring ZCA components in their 

And this policy means that BFG (and maybe more of the Repoze stack, if 
it's a direct dependency of BFG) has now effectively written itself out 
of using *any* zope.* package bar the most basic ones that don't use 
ZCML in the zope:* namespace. That's a very small set of Zope packages. 
And potentially it's a growing list of packages that will need to 
be-implemented or forked for Repoze's needs.

I guess I'm saying if I owned BFG, I'd make a different trade-off. I'm 
not telling you to do what I would do, though I think it's incorrect to 
say that "everybody wins" by this.

> Remember, each time you want to say "transitive dependencies", you  
> should replace it with the more accurate "harmful side-effects".

Mmm.... I'm not sure they're quite so harmful, although I agree that 
trusted adapters are a bit weird. Would they actually break a BFG app if 
used, or is it just that you haven't thought about using them? And is it 
worse to give people the possibility of (ab)using them in a BFG app than 
to fork Zope's configuration machinery? Maybe. Maybe not.

> 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  
> application server.

Sure. It was just an example, though, to illustrate that BFG apparently 
doesn't want almost anything of zope.* (bad grammar). That wasn't 
obvious to me. If that's the intention, then that's of course perfectly 
fine, although it makes BFG less attractive to me, personally, because 
it means I'm dependent on a smaller community of maintainers and users. 
Again, not a criticism, just an observation and a data point.

But, as we've seen, this policy almost by necessity has to be pushed 
down into other repoze.* packages where they straddle the worlds of the 
ZCA and BFG. Since a lot of the Repoze project's effort is going into 
BFG these days, that seems like a logical conclusion. Again, this may 
make future and current repoze.* packages less attractive to Plone and 
other users who want more of zope.*. Again, not a criticism, just an 

Although here is a slight criticism: Plone trunk is (probably) in the 
process of adopting Chameleon. I'd argue that repoze.zcml is not really 
an appropriate dependency for Plone, or at least one we'd rather avoid 
if we could. Yet here a BFG-driven decision meant that Plone now has to 
swallow this dependency, and there doesn't seem to be a lot of 
consideration that this could be a valid point of view. If Malthe's 
happy with this, I'll shut up and write some documentation to tell 
people that the bfg:adapter/utility/whatever directives are not to be 
used in Plone and hope no-one gets confused, or find some other 
compromise. I can't tell you what to do. But I can voice the concern, 
not at least because this point may not have been obvious to Chris (who 
possibly didn't know that Plone trunk has optional Chameleon support at 
this point).

> I think, fundamentally, that's the issue.  You want to sign Chris up  
> to fix Zope3.  He wants to work on Repoze and BFG.

You've got to admit it's a fine line to tread when you don't want to 
sign up to something as fundamental as Zope's core ZCML handlers, 
though. And the experience from Plone is that sometimes this is a costly 
policy in the long run. It's a piece of advice. Take it or leave it.

>> 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.
> It has been explained to you that this is more than a mere packaging  
> discussion.  Possibly you disagree, as you still paint it as  
> "untangling dependencies".

If Zope had a cleaner dependency structure that made things like and trusted adapters optional, repoze.zcml wouldn't be 
needed, right?

> 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?

I'll do my best to contribute constructively. I'm probably not going to 
bother with this debate any more, though, as I've said what I wanted to 
say and it's getting a bit silly and lengthy.

> 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.

Yep, but Grok's model is sufficiently different to be less confusing. 
And Grok hasn't talked itself out of using the majority of zope.* 
packages due to this configuration system. We're comparing apples and 
oranges, though, since Grok is most definitely built atop Zope 3.


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

Repoze-dev mailing list

Reply via email to