Summary: there isn't really a problem, because BFG is not Repoze.   
People that want the side-effects in BFG can still get them.   
Everybody wins.

On Dec 21, 2008, at 6:06 AM, Martin Aspeli wrote:

> I realise Plone isn't your main concern here, but this is basically
> what's going to happen to anyone who use lower level Repoze components
> that use this means of configuration in a non-BFG context (or at least
> in conjunction with more general Zope stuff).

I don't see why this is true.  Chris changed BFG, not Repoze.

Chameleon changed, and if Plone does or doesn't use Chameleon,  
Chameleon-in-Plone simply needs to internally do something tiny.  It  
already internally imposed lxml as a requirement.  This change is  
*tiny* compared libxml2+lxml+Cython.

I'm not sure it is true that use of any "lower level Repoze  
components" has changed.  Since this seems to be the heart of your  
point, can you illustrate where this is true?

BFG is not Repoze.  BFG certainly isn't trying to be Zope, and thus,  
shouldn't sign up for the mound of policies that Chris did the  
analysis on.  You didn't comment on his writeup, though: do you concur  
with his point, that the package list is laden with (harmful for non- 
Zope) policy?

Frankly, the "more of an island than it already is" lead-in comes  
across as an ill-informed insult.  BFG starts with easy_install, then  
virtualenv, then Paste, then WSGI, then WebOb, before you even see  
BFG.  It ships with Chameleon: when do you suppose Zope 2/3 will  
replace ZPT with Chameleon? BFG doesn't even *include* ZODB, much  
less, require that you have a root before you can write your non-ZODB  

I think we're working harder to hang out with other Python web  
technologies than anybody else in the Zope world, by far.  You have a  
weird definition of "island".

> I think that's a shame, because it's an argument against adopting  
> Repoze
> components in other frameworks. Plone already has far too many
> almost-identical-but-not-quite ways of configuring things and we're
> trying hard to consolidate. We don't have to use repoze.zcml ourselves
> (and we almost certainly won't), but as people try to understand the
> stack, it's another thing they have to be aware of. As we start using
> more Repoze components (trunk already pulls in siz repoze eggs) it's
> something we may start bumping up against higher up in the stack than
> the template engine.
> From experience, it's not unlikely that people will then start copying
> the approach used by Chameleon and then get rather confused when they
> realise that <utility /> can mean two subtly different things  
> depending

Yes, because the policies in <utility/> can be harmful when used  
outside of Zope.  Chris is doing the responsible thing: not giving  
false advertising that this is the same set of <utility/> assumptions  
as Zope.

Hopefully you're not arguing that BFG should, for example, adopt the  
idea of non-trusted code, just to make sure we use the same ZCML  

> on an xmlns line at the top of their configure.zcml.
> I'm not saying what you've done was bad for repoze.bfg, but at least  
> be
> cognisant that repoze.bfg and by extension, possibly the wider repoze

That seems like a false leap.


> stack, is starting to smell more like a fork of "Zope" (or at least a
> particular combination of various Zope components), that's going to  
> make
> the attractive bits of the stack harder to swallow for other users  
> of Zope.

Repoze-dev mailing list

Reply via email to