[Zope-dev] Packaging Zope for Fedora

Andreas Jung lists at zopyx.com
Sat Mar 22 03:05:42 EDT 2008



--On 21. März 2008 13:39:08 -0700 Timothy Selivanow 
<timothy.selivanow at virtualxistenz.com> wrote:

> On Fri, 2008-03-21 at 20:09 +0100, Andreas Jung wrote:
>> Hi,
>>
>> speaking as the Zope 2 release manager: I am strongly opposed against
>> splitting Zope yourself into different packages and modules. With Zope
>> 2 depending from various Zope 3 packages (roughly 80-90) we have
>> already the situation to keep track which packages belong together.
>
> My concern is more with striping out the non-Zope pieces.  If there are
> pieces of Zope that are useful outside of Zope (e.g. in some other
> project, or someones personal code...) I thought it would be nice to
> offer those as a separate piece so that someone could use just that
> piece.  Having 80-90 different RPMs _would_ be rather unmaintainable.
> I'd only pull out the first few useful ones, and then others by-demand.
> My biggest concern is removing the non-Zope parts.

In general we want to get rid of 3rd-party packages we don't want to 
maintain on our own. Right now we have several 3rd-party packages like 
Docutils in our svn for several reasons. Some of those packages are 
basically frozen (because we made local changes e.g. for security reasons).
So if you rip out those packages you have to guarantee that they will 
_never_ be updated by a new official package (because local changes might 
get lost). On the other hand you must ensure that changes to our local
3rd-party packages will be available through your packaging mechanism.
As said: this is a challenging task for us right now - it will be even more 
challenging and more error-prone for outsiders.

>
> As far as Zope2 is concerned, I'll cross that bridge later.  Newest
> technology is /generally/ the focus of Fedora.
>
>> This will become even more complicated when each Zope 3 package will have
>> its own life-cycle. I doubt that you as a package can keep track in a
>> reliable way with those requirements. It is somewhat hard for me to
>> follow.
>
> The Eclipse project has done an awesome job, and so has Fedora in
> keeping up with it (they actually work very closely together).  I'm not
> concerned with ripping Zope /completely/ apart, but rather I
> thought /some/ parts might be useful by themselves, like the ZODB for
> example.

Since Zope (2+3) are officially only blessed for Python 2.4 you'll have 
problems if you're going with the newest Python 2.5 or even 2.6 version.
The trend in all Zope-related projects (Zope 2,3, Grok, Plone) is 
definitely: self-contained installation. Why self-contained? Different 
projects require different modules in different versions. Messing a Python 
installation with e.g. ZODB from different versions will end up in an 
disaster. So the message of the Zope community is in general: keep your 
Python installation clean and use zc.buildout or virtualenv for installing
your other modules within an isolated environment. This is meanwhile 
considered best-practice. Using Python eggs and easy_install you have _the
official_ tools in your hand for installing 3rd-party packages..that's the 
Pythonic way to do it, not using some distro packaging tool.



>
>> So why can't you leave the Zope source packages as they are? Splitting up
>> Zope into even more packages is even more error-prone.  Re-packaged Zope
>> distributions always raised more problems in the past than they really
>> solved. The deployment for Zope-based applications is nowadays based on
>> zc.buildout.
>
> So, are you saying that you would rather Zope not be in Fedora, or any
> other distro, and just leave it up to the user?

This was never my point. For me it would make more sense that the packages 
would take the official release and re-package it as a whole without 
splitting it up. Dependency management should happen on our side as a whole,
not on the distribution site. I don't know how important Zope distro 
packages are for users. My personal impression is: not so important. Zope 
packages at this point might be good for getting into touch with Zope but 
for deployment packages are basically no used - but correct me if I should 
be wrong. Since a while we have tools in place to bootstrap Zope 2/3 
projects, Plone installations and Grok installations very easily and in a 
reliable way. I know that those approaches don't comply directly with your 
package mechanisms but I would expect that the "offical" installation and 
deployment stories by the Zope community should be taken into account (in 
some way).


>
>> Serious solutions providers never go with distribution-specific packages.
>
> Some do, but that's not the focus of me packaging Zope.  Since Fedora's
> focus is not for production (yes, people do use Fedora in production,
> e.g. NASA, but that is their onus), but rather development and blazing
> new trails.  This would provide more code and utilities for people to
> use and experiment with.


See above. Distro specific package are perhaps another change for gettting 
into touch with Zope but I am not sure how important that is. I can imagine 
that people hear of Zope technology and then visit the related webpage and 
check the installation notes (which are basically not specific to a 
dstribution).

One last thought: you might check out the packaging efforts by the Plone 
project. They provide possibly also packages for Fedora on their own (which 
includes Zope 2 afaik (the "universal installer")). It might make sense to 
share experiences with them and leverage from their experiences.

But don't get me wrong. I have nothing against distro-specific packages but 
they should be done in the right way. "Right" means for the user: they are 
consistent with the official documentation and best-practices as used 
within the offical Zope world - "Right" for the supporters within the Zope 
world: we don't have to deal with issues caused distro-specific packages 
(e.g. configurations are different from the standard, paths are different 
from the standard etc.).

Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://mail.zope.org/pipermail/zope-dev/attachments/20080322/84220408/attachment.bin


More information about the Zope-Dev mailing list