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 

  - 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 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

Repoze-dev mailing list

Reply via email to