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 > untangled. > 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 > everyone.
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. > Does > 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 > lot > closer to a BFG philosophy that's not necessarily going to be > compatible > 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. Everybody wins. > What about the other repoze.* packages? Which ones are going to > inhibit 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 > of > 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 > either > ends up being more monolithic (i.e. owning its own, tightly > controlled, 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 tightly-controlled monolith. 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 > things > like configuration into lower level packages, because dependencies > can't > 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. --Paul > > > Martin > > -- > 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@lists.repoze.org > http://lists.repoze.org/listinfo/repoze-dev _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
