Future of python2.6 in Debian

[Toni Mueller]

Hi,

On Wed, Jun 06, 2012 at 10:27:39AM +0900, Arnaud Fontaine wrote:
> Toni Mueller <toni at debian.org> writes:
> >> +1.  Time  to retire Python 2.6.   From Bernd's reply it  sounds like
> >> the Zope upgrade needn't block this.
> >
> > please DON'T!
> >
> > I am  a heavy  Zope user,  and, as others  stated already,  the Debian
> > packages for  Zope are useless. Sorry  to say it that  way, but that's
> > what it is. This has nothing to  do with the way the Zope packagers in
> > Debian work, just with a gross mismatch of release cycles.
> 
> Could you  please elaborate on  that? It would  be really useful  to get
> some feedbacks from users actually ;-). Thanks.

the Zope packages are imho generally useless for actually running Zope
and Zope applications, for the following reasons (but I do not claim
completeness, nor attribute meaning to the order in which I present the
issues):


 * The Debian release cycle and the Zope/Plone release cycle greatly
   diverge. Typically, every Plone release requires a specific Zope
   release, and cannot easily be run on a different Zope release, if at
   all.

   Eg. until not-so-long ago, Plone 3 was the thing to use, and it used
   a Zope version that required Python 2.4. Since some time, it's Plone
   4.[01] that requires Python 2.6. Only the still-in-beta Plone 4.2
   even works with Python 2.7 (but 2.6 is still supported). On the Plone
   list and IRC channel, you can still find frequent questions about how
   to migrate from 3.x, or even 2.x, to 4.x (I am approaching this
   problem by using virtual machines with suitable older versions of
   Debian).

   Several points made below are just illustrations of this problem.

 * The same thing holds for many of the components in a Zope
   application: Their versions are tied down with the release, and other
   versions are typically not easy to use - usually, they break the
   site. This even starts with distribute, where you have to have a
   certain version, not necessarily that shipped with Debian.

 * Upgrading heavily depends on the availability of third-party
   products, of which there are many, many of which are not packaged for
   Debian, or not possible to package for Debian with suitable effort.
   Downgrading is generally not supported, and just impossible.
   This contriutes to the divergence in release cycles. If you eg.
   move an application, you have to minutely reconstruct the environment
   on the target server. Going with the shipped packages with different
   versions is usually impossible.

 * Since versions required by Zope and Plone are often different from
   those shipped with Debian, or any other operating system for that
   matter, about the only sane way to run a Zope application is to use a
   virtualenv, and you even have to create it using --no-site-packages
   to be on the safe side (I've once forgotten to specify this, and
   great havoc ensued).

 * Deployment scenarios of Zope applications cannot reasonably be
   anticipated in the package management. Not only are there many
   different ways to do it, for a popular site, there is typically
   also a three- or more-tier structure involved:

   ZEO server - Zope server(s) - cache server(s) - front end reverse proxy

   In additon to that, these components are often scattered over several
   pieces of iron, and accompanied by things like supervisord to keep
   things running. Since the cost of having a Zope site typically only
   pays off if you have a certain minimum size, the field is dominated
   by professional applications that have to be sized to handle some
   kind of load.

   I am unaware of a Debian way to deploy multi-machine, multi-component
   applications.

 * Debian Security, while generally doing a brave job, is generally too
   slow for Zope/Plone. Although security problems have been thankfully
   not very frequent, some high-risk problems have been found recently.
   These forced users to patch within hours.

 * You need to be able to run various versions of Zope + stuff in
   parallel. Eg. for a Plone 4.0 site, you have to have different
   versions for packages than for a Plone 4.1 site, and the packages for
   Plone 4.2 will be different again. You can easily end up needing them
   all in parallel. This does even pertain to zc.buildout - you need a
   suitable version for your project, and if you have more than one
   project, you may easily end up needing more versions of it.

As others said already, zc.buildout is the way to go in the Zope area,
and everything else is basically asking for trouble, intractable, and
unsupported by the community.

But having a solid Python + distribute + virtualenv stuff in the base
system, still "feels" much, much better than dragging a stock upstream
Python into the system, several times, then go with that what is shipped
upstream, and often seems to be abandoned (since they want everyone to
use the latest and greatest). The Unified Installer for Plone carries
their own version of Python along, but this package is intended for
beginners only, not really for production use.


Summary: I don't see how Debian can fix all these problems (and more) at
once, but suggest that there be good Python (the language interpreter +
stdlibs) packages in Debian, thus providing a robust and friendly
environment, and leave the rest to the application developers and users.


But I also have a question. You wrote:

> Could you  please elaborate on  that? It would  be really useful  to get
> some feedbacks from users actually ;-). Thanks.

This suggests to me that you too are not users of these packages? If so,
why aren't you using them? Or if I misread you, and you are a user of
these packages, how do you cope with the problems outlined above?


Kind regards,
--Toni++