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"
>>>> that should be re-usable and may be useful to BFG if it ever wants
>>>> serialise Zope 3 schema interfaces to/from an XML representation)
>>>> it uses zope:* ZCML directives. Are you going to fork
>>> 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
- 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.
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