Paul Everitt wrote: > On Dec 22, 2008, at 1:06 PM, Martin Aspeli wrote: > >> Wichert Akkerman wrote: >>> Previously Martin Aspeli wrote: >>>> If you want to pull in, say, plone.supermodel (a "pure Zope 3" >>>> package >>>> that should be re-usable and may be useful to BFG if it ever wants >>>> to >>>> serialise Zope 3 schema interfaces to/from an XML representation) >>>> well, >>>> it uses zope:* ZCML directives. Are you going to fork >>>> plone.supermodel? >>> I would be very tempted at least. Or decide to not use supermodel. >> Which would mean that the BFG-intersecting parts of the repoze stack >> would be a fork or re-implementation of all Zope stuff that was >> interesting to it. I don't think that's a sustainable way forward. >> Or at >> least, then repoze should stop billing itself as "the maturity of Zope >> now with the flexibility of the WSGI future". > > Demonstrably false. Please list the Repoze components, particularly > the ones Plone is using, that were affected by this change.
Paul, I'm not sure if you're just being facetious now... I've listed it in every email in this thread, and it's getting a bit irritating having to repeat it. Plone uses Chameleon. Chameleon is in the Repoze repository. Chris changed Chameleon. Plone is affected. If there are parallels with Chameleon (things that BFG want to use, that use the ZCA and depend on Zope 3's standard ZCML handling) then those will necessarily need to follow the same path. This may make those packages less attractive re-use in Zope 3-dependent projects and I think we should at least acknowledge that. Plone is starting to embrace the Repoze stack in a big way. I don't think it's unreasonable of us to want to investigate the motives behind the people working on Repoze to understand how the Repoze development roadmap may affect Plone in the future. So, here's what I've learned, and correct me if I'm wrong: - BFG does not intend to be part of the "Repoze" stack quite in the way that Repoze is trying to bridge the Zope and WSGI/Python worlds. This wasn't clear to me, but then I've never claimed to be deep into BFG either. - BFG has little interest in re-using the various zope.* packages beyond the very core zope.interface and zope.component. - Where BFG does want such a package, it may need to fork or re-implement it to avoid a transitive dependency on zope.security and friends. This is a trade-off the BFG developers are willing to make for the sake of a smaller dependency graph and less code in the stack that doesn't work well with BFG if used. - There may be a conflict of interest where a BFG dependency that uses the ZCA is re-used outside BFG, because of the different ways to configure components. This is something we'll have to manage, I guess. I am happy to leave it at that. It doesn't make me think that using repoze.zope2 and related middleware in Plone is a bad idea. I think the Chameleon change is a bit troubling, but Chris' suggestion to push the configuration further up in the stack, making it a documentation issue, is a good one IMHO. 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
