Benji York wrote:
> On Wed, Sep 3, 2008 at 8:40 AM, David Pratt <[EMAIL PROTECTED]> wrote:
>> I am trying to avoid the need for selective forking that Chris has found
>> necessary to make progress with bfg. I want to continue using zope [...]
> +1 Experimental forks to help determine what refactoring need to be
> done in the "mother" package are fine, but I hope that the findings of
> Plone, Grok, and repoze/bfg can all be folded back in.
Agreed with this. We want Zope 3 packages to move forward, so I'm very
glad that David took up this discussion. It's important we develop a bit
of vision here, some guidelines, and a plan on how to get there step by
Note that Grok hasn't been forking Zope 3 packages. We've built a few
packages on top of Zope 3 that are now reusable with straight Zope 3
too, to wit, grokcore.component, grokcore.view and grokcore.security and
soon grokcore.formlib. Grok has its own approaches of course, but one
thing we spent quite a bit of time on is to be good Zope 3 citizens.
Grok 0.14 will be built on top of these grokcore.*, and we took pains to
make these compatible with straight Zope 3 projects as well. This means
that if you want Grok-style configuration of adapters, views and
utilities in your Zope 3 project or library you can use these projects.
I have a few z3c packages sitting around that I hope to convert to use
these once Grok 0.14 is released. These packages are already finding
some uptake in Zope 2 projects as well. It's been interesting to see how
the requirements to reuse bits of Grok in Zope 3 and Zope 2 have been
pulling togeter to help factor these packages out.
I think the only bit that you can really consider a 'fork' is
grokproject itself, which is like an improved zopeproject. If someone
wants to take it up, we could start factoring out a common core there as
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -