Hi, On Wed, Jun 06, 2012 at 10:27:39AM +0900, Arnaud Fontaine wrote: > Toni Mueller <t...@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++ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120606105106.gb15...@spruce.wiehl.oeko.net
