On Dec 21, 2008, at 11:36 AM, Martin Aspeli wrote:
> Paul Everitt wrote:
>> That seems like a false leap.
> I freely admit to using hyperbole in my original email to draw out a
> debate. :-)
> It does bother me a little, though, that the "fix" seems to be to
> fork/re-implement rather than to try and push something downstream.
> No-one in Zope is disagreeing that the dependencies should be
> Few people seem to have the time and impetus to do something about it.
> When BFG does, then it'd be great if that effort could benefit
Chris provided an analysis showing that this is more than packaging.
There are policy decisions involved. Could you comment on his writeup
about the policies and side effects?
Should people that want to use Zope-style components, also be forced
to digest "trusted adapters"? Or, is someone brave enough to convince
the Zope world to either ditch that idea? Or, shepherd a proposal to
make it parameterizable?
It isn't their itch, so they won't implement the proposal. Instead,
you'll be asking the people that *don't* want trusted adapters, to do
the work to paramaterize it.
Thus, this is harder than just untangling dependencies, IMO.
> My specific reaction, by the way, was not to BFG, but to Chameleon.
> chameleon.zpt "belong" to BFG? This wasn't my impression. And if so,
> does Plone need to be wary of adopting it, for fear of it growing a
> closer to a BFG philosophy that's not necessarily going to be
> with Plone's architectural vision going forward?
I presume that Chameleon belongs to Malthe et al. I doubt a change
would be made that he disagreed with.
But I'll invert the question: does Chameleon belong to Zope? I
believe Chameleon aspires to life beyond the Zope island. If so, then
it is a Great Thing to shed those rather harmful side effects, while
enabling a *TRIVIAL* way to sign back up for them in Zopeland.
> What about the other repoze.* packages? Which ones are going to
Yes, you made this assertion, and I'm asking you to demonstrate the
facts behind that assertion. Are you claiming that repoze.zope2 has
changed? repoze.retry? repoze.tm? repoze.who?
> this parallel universe where things are done almost like other parts
> Zope, but not quite? After ZCML, what's next?
Hopefully, lots of stuff is next, but for BFG. Repoze is the place of
co-habitation with the goals of fidelity.
> There is an obvious risk here, as demonstrated by the chameleon.zpt
> case, that the desire to prune transitive dependencies means BFG
> ends up being more monolithic (i.e. owning its own, tightly
Calling bfg a monolith is, like calling it an island, just plain
silly. BFG is the opposite of a monolith, as I demonstrated in my
previous mail. Also, BFG does not have the goal of fixing Zope's
Again, Chris spent the time to show that this is more than pruning
transitive dependencies. This is pruning harmful (to non-Zope), side-
effect-ful (to non-Zope) policies that are part of the goal in Zope.
> minimal versions of everything) or pushing alternate methods for
> like configuration into lower level packages, because dependencies
> be kept to an absolute minimum otherwise. Re-use always carries a risk
> of getting more than you bargained for, because the author of the
> original package may not have intended it to be re-used in exactly the
> way you need.
> But sorry about the "island" gripe - I'm very grateful for the work
> repoze is doing to play well in Python land, and, as you know, I'm a
> strong advocate of Plone and Zope riding that bandwagon. I just worry
> that sometimes this may mean leaving the rest of Zope behind, rather
> than work to bring it along.
Chris has worked hard *in Repoze*, harder than just about anybody
else, to bridge the gap and bring it along. He's asking that BFG be
his own place, where he can build just the thing he wants, and leave
out the parts he doesn't want. People don't have to use it if that
isn't their goal.
> Author of `Professional Plone Development`, a book for developers who
> want to work with Plone. See http://martinaspeli.net/plone-book
> Repoze-dev mailing list
Repoze-dev mailing list