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.
If repoze.zcml was named zope.zcml (or zope.zcmlthatdoesless or whatever), would that help? The only other option would be to convince the "test what you fly, fly what you test" crowd that we really do need permission/trusted-less ZCML directives "in the core", and that they'll need to undergo some pain (and cease contributing stop energy to the discussion) to allow us to get what we need. I've never been very successful at that, so I just avoid doing it. > 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? Chameleon belongs to those who help maintain it, IMO. Primarily this means it belongs to Malthe, who has written 99% of its code. I checked into it yesterday a dependency on repoze.zcml. I did not get permission to do so from Malthe. But unless I have a very poor sense of judgment, I suspect Malthe will cheer about shedding four dependencies. As far as architectural vision, Plone makes a lot of sacrifices for backwards compatibility, all of which are reasonable in the context it's developed in. They make no sense, however, to other projects, and Plone can't expect other folks to live with them forever because it has chosen to. But if change *is* desired, there is some responsibility incumbent upon Plone devs to get with the program here and bring some pressure to bear; you've seen that Zope 3 development is currently landlocked, right? Every time somebody brings up some moderate change on zope-dev, it's more or less immediately shot down by the folks that don't want to think about it. What other choice do we have but to fork? > 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? The good old slippery slope argument. But admittedly there's some truth to it here in the context of BFG... for BFG, what's next is whatever we goddamn well please. ;-) (This doesn't really extend to other repoze packages, FTR, just BFG). If we can help Zope in the meantime, great. > 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. Any package the Zope world would develop to solve this problem would smell almost exactly like the one implemented in repoze.zcml. So there's a blueprint. Let's figure out how to put it in the core, or not. 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. Taking action is the best way to move things along. It got you interested, didn't it? ;-) - C _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
