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 _______________________________________________ Zope-Dev maillist - [email protected] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
