repoze.bfg has a core concept of "pay only for what you eat", so, as Paul put it
(with a 30 point word no less!), "fidelity" with Zope is not a goal; where we
don't need things that Zope offers, we explicitly get rid of them. This helps
keep things honest and understandable, particularly in places where concepts
overlap ("why do I need zope.security when BFG has its own security? why do i
need zope.traversing when BFG does its own traversal? why do i need
zope.publisher when BFG has its own publisher?").
You understand this goal, as below you argue for it in the context of Plone. I
am sorry it needs to be one way or the other currently (either bfg gains four
dependencies and directive attributes that are actively harmful or Plone gains
one dependency), but that's how it is until we can figure out a way to get
everybody what they want. But one thing won't happen: bfg is not going to live
with four inappropriate dependencies forever to service a goal of fidelity. So
we can either figure out a single way that everyone wins, or we leave it as is.
That's the set of options you lobbied for me to choose from in your original
email, so I present them back to you, where that decision is yours to make
instead of mine.
That said, to the extent that we can push functionality down into Zope bits and
help detangle dependencies in the course of doing the cleanup, we'll definitely
do so. But if cleanup is vetoed, we are going to fix it one way or another.
- C
Martin Aspeli wrote:
> Chris McDonough wrote:
>
>> That package is now done...
>>
>> http://static.repoze.org/zcmldocs
>>
>> and
>>
>> http://pypi.python.org/pypi/repoze.zcml/0.1
>>
>> I've adjusted the trunk of bfg and the trunk of chameleon.zpt to use ZCML
>> declaration implementations from this rather than using the "stock"
>> implementations from zope.component.
>
> Given that Plone also uses chameleon.zpt (via five.pt) this means that,
> if I understand correctly, Plone now gains this dependency, and part of
> the Plone stack uses what will seem to most people like an arbitrary,
> almost-identical-but-not-quite way of configuring components that's
> different to what the rest of the stack uses.
>
> 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 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
> 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
> 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.
>
> Martin
>
_______________________________________________
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
