[Zope-dev] Re: Renamed the Zope package to Zope2 and including Zope 3 packages in Zope 2.8

[Martijn Faassen]

Jim Fulton wrote:
> Would it make sense to have Zope 2.8 include all of the packages
> below other than zope.app and for Five to supply it's own zope.app?

It would make life harder for Five, and create more work for us, as we'd 
have to worry about:

* shipping a zope.app ourselves (does it contain binaries? will it ever 
contain binaries? Right now we can just lift along ZopeX3 releases)

* we'd have to worry about version skew. Suddenly we're locked into 
whatever versions of the Zope 3 code is in Zope 2.8 and whatever version 
of zope.app that works with that version. Right now Five is completely 
free to track ZopeX3 releases and there is no worry about version skew.

If there is a knob to turn off anything Zope 2.8 ships then life would 
be a bit harder for people installing Five, as it'd need an extra 
zope.conf switch besides the path to Zope 3 that already needs to be 
there. It's doable to document this though.

As to Five, this whole exercise, no matter what packages are copied, 
only makes life harder, not easier. I was looking to go this way 
(including more zope 3 stuff into zope 2) a year ago, and decided I 
couldn't make progress that way, as I had to wait for all kinds of 
things I couldn't control easily, like Zope 2.8 and the Zope 2+3 
interface compatibility package.

Then I got to liberate zope.interface from the one incompatibility that 
really prevented Five. After that, Five was ready to be freely 
developed, independent of the unpredictability of Zope 2 *or* Zope 3 
releases. Any addition of Zope 3 code to Zope 2 will make life harder there.

I understand that for a future version of Zope 2, Zope 3 code will be 
included.

I understand one direct use case is some Zope 3 persistence system that 
can be used to help with ZClasses.

I understand one other set of use cases is to make it possible to start 
using Zope 3 technology in Zope 2 (this use case could also be fulfilled 
by something like Five).

I can also see an ease of deployment use case -- no huge Zope 3 package 
to download and install separately. Then again, such a separation 
between the projects does make life easier sometimes, as is evidenced by 
the trouble Five would get in with more mixing.

What other use cases are floating around?

I cannot judge how likely version skew is between zope.app and the parts 
of the zope package that will be in Zope 2.8.

Anyway, more work for Five developers doesn't mean this shouldn't 
happen, but perhaps a review of the use cases driving this would be 
helpful. If it's really only about making ZClasses work in Zope 2.8, is 
this really the only way forward? If not, I'd prefer to stick to the 
original plan, and wait for Zope 2.9 before Zope 3 integration starts to 
happen.

Regards,

Martijn