[Zope-dev] Dependencies and future of zope 3

[Martijn Faassen]

Benji York wrote:
> On Wed, Sep 3, 2008 at 8:40 AM, David Pratt <fairwinds.dp at gmail.com> 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 
step.

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

Regards,

Martijn