Stephan Richter wrote:
> 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
> 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
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
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
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -