[Zope-dev] dropping Python 2.4 support in the Zope Toolkit?

[Wichert Akkerman]

Previously Martijn Faassen wrote:
> This is a component developed in the context of the Zope Toolkit (or at 
> least post-Zope 3.4). It depends on zope.container, also new. We 
> released a backwards compatible zope.app.container (not in the Toolkit) 
> which relies on zope.container now for its implementation. The previous 
> version didn't, so you'll need to use this newer version of 
> zope.app.container too, otherwise you'll end up with two implementations 
> of Container in a single codebase, which seems dangerous. There's also a 
> similar issue with zope.app.component (where some of the functionality 
> moved to zope.site, some to other places).

Looking at a project I'm working on I use the following zope packages:

zope.sqlalchemy trunk
zope.location 3.4.0
zope.component 3.4.0
zope.security 3.5.2
zope.testing 3.7.1
zope.i18n 3.4.0
zope.proxy 3.5.0
zope.intid 3.7.0
zope.app.zcmlfiles 3.5.3
zope.securitypolicy 3.4.0
zope.container 3.8.1
zope.app.publisher 3.5.2
zope.keyreference 3.6.1
zope.broken 3.5.0
zope.browser 0.5.0

This works today in Plone 3.3. It's a bit painful to find a set of versions
which work well together with all the current refactoring, but as you can see
it is possible, and extremely valuable for us. 

> But it does mean replacing huge parts of the Zope 3 underneath of a 
> release of Plone just so people can install a new version of z3c.form... 
> And hoping that the zope.app.* packages (not in the toolkit) will 
> continue to work.
> 
> What I'm trying to point out that using the Zope Toolkit with an 
> existing release of Plone is risky. In general, I don't think we can 
> realistically support existing releases of complicated applications of 
> Plone with new releases of our libraries. Of course we try to stay 
> compatible, but you'd expect those applications to do some testing 
> before they can upgrade to the new versions in a new release.
> 
> Anyway, if I'm correct, the argument in favor of Python 2.4 support in 
> the Zope Toolkit is as follows:
> 
> * Plone is still on Python 2.4 and Zope 2.10
> 
> * Plone would like to use libraries like z3c.form 2.0 that already are 
> on the Zope Toolkit
> 
> * in order to do this, Plone developers will tell users of 
> z3c.form-based code on Plone to replace vast amounts of libraries in 
> their Plone install with Zope Toolkit libraries.
> 
> * the Plone developers will make sure that this works so that the Zope 
> Toolkit developers don't have to worry about it.

We do expect some help. If we end up in a situation where people can not
use Plone with more recent ZTK goodness, and they can't use ZTK without
all the benefits of Plone we will loose them to non-zope systems. 

> * the Plone developers are asking not to drop Python 2.4 support in the 
> Zope Toolkit now because they want to do such a thing.
> 
> The question now is whether this is realistic from the Plone 
> perspective.

To some degree I consider it essential even. At the moment we are in a
position were we have to deal with the fact that Plone runs on Zope 2.10
while we want to be able to use ZTK components in order to be productive
and have a modern environment. Just like Hanno almost all my Plone
projects over the last year have had to do this.

Wichert.

-- 
Wichert Akkerman <wichert at wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.