Summary: there isn't really a problem, because BFG is not Repoze.
People that want the side-effects in BFG can still get them.
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-
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
> 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
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
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
> 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
> the attractive bits of the stack harder to swallow for other users
> of Zope.
Repoze-dev mailing list