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

[Martijn Faassen]

Hey,

Stephan Richter wrote:
[snip]
> I do think that we should care a lot about the Plone user base. Right now it 
> is by far the largest sub-community we have. 

I care about the Plone user base, but would you really have said: "okay, 
we should not move to Python 2.5 for Zope 3.5, because people on Plone 
which is still based on Zope 3.3 may want to use bits from Zope 3.5?"

I don't think you would have.

I seriously think that people who think they can just drop in Zope 
Toolkit components into an existing Plone release might not see the true 
difficulties involved. If this is the only argument to stay compatible 
with Python 2.4, then it is a bad one.

You give another argument, which is a better one:

> Let me give you an example, 
> where I think that dropping Python 2.4 support in general will actually 
> massively increase the compatibility burden elsewhere.
> 
> Plone is using z3c.form. We are currently in the process of releasing z3c.form 
> 2.0, which has a massive amount of new features, which are very useful. As a 
> z3c.form developer I want to stay compatible with the current Plone release, 
> because (a) the code gets tested in a very different environment, and (b) it 
> probably represents my largest user base. 

> By dropping Python 2.4 support for 
> the Toolkit, I now have stay compatible with 2 or 3 versions of the KGS (Zope 
> 3.3?, Zope 3.4, Zope Toolkit 1.0) and 2 or 3 Python versions (2.4, 2.5, 
> 2.6?). This is a major burden. The problem is that I have this burden for 
> every package that I care about to be usable in Plone.

This is an argument of wanting to build a single component that stays 
compatible with rather wide range of versions of the underlying 
libraries. Perhaps Martin Aspeli was hinting at this earlier.

Looking at the z3c.form trunk and it's setup.py, I see it relies on 
zope.site.

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

So, mixing zope.app.container old-style with zope.site newstyle is a 
recipe for trouble, and it's not very obvious trouble. The Plone 
developers are used to trouble though, so let's continue...

Plone 3.2 relies on Zope 2.10.7. This pulls in the full Zope 3.3.

Assuming you can override individual Zope 3 packages in this setup (I 
don't know whether this is possible as it just installs Zope 3.3 as a 
whole, but I assume you can), you'll have to override *all* of those 
packages in Zope 3 that are also in the Zope Toolkit, otherwise you'll 
have trouble.

This might work. It might even work by accident if you replace less 
libraries, but I'd certainly worry quite a bit doing that...

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.

* 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. Have people tried this? Do the z3c.form tests run, and the 
Plone tests? Have people done this with Zope 3.4 libraries (which have 
been released for a while)? Or have things just worked based on luck and 
magic? (since Plone never actually uses a Zope Toolkit container 
implementation it hasn't been an issue that there are two versions in 
the same codebase, say)

How hypothetical are the scenarios we're talking about here?

All too often in the past we've *not* done things because someone 
somewhere has an argument, possibly quite weak and unrealistic, to hold 
up the process. I'm all for listening to people's arguments, but in 
order to make progress we must also be willing to disappoint people 
sometime.

Regards,

Martijn