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.

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

Repoze-dev mailing list

Reply via email to