Paul Everitt wrote:
> That seems like a false leap.
I freely admit to using hyperbole in my original email to draw out a
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.
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?
What about the other repoze.* packages? Which ones are going to inhibit
this parallel universe where things are done almost like other parts of
Zope, but not quite? After ZCML, what's next?
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,
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.
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