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".
> But I don't think that's what Paul or Chris would want. :)
BFG is a bit sideways to the goals of "the Repoze stack" (which is actually what
that tag line refers to, rather than BFG). If I had it to do all over again,
"repoze.bfg" would be named just "BFG" (without the "repoze"). I doubt it's
possible to make this change now, apologies, folks will just have to understand.
Please try to make the mental jump required to separate WSGI middleware and
libraries labeled "repoze" (like repoze.errorlog, repoze.tm, repoze.squeeze,
repoze.monty, etc.) and BFG itself. Conflation of BFG with the rest of the
repoze stack that is explicitly meant to be middleware and libraries is a
Repoze-dev mailing list