[Zope-dev] Re: [Zope 2.12] Eggification of Zope 2 - pros and cons?

[Martin Aspeli]

Philipp von Weitershausen wrote:
> Andreas Jung wrote:
>> during the latest 'zope.publisher' thread on zope-dev I came up with
>> the proposal to eggify the Zope core for the Zope 2.12 release. I would 
>> like to start a discussion about the pros and cons, risks and advantages 
>> of any eggification effort.
>>
>> Chris favors a 'big' Zope egg with some dependencies (like ZODB) 
>> stripped out.
> 
> I have pretty much done this already. [1] defines an egg called 'Zope2'. 
> All the Zope 3 eggs are dependencies, as are a few "non-core" packages 
> such as ExtensionClass, Acquisition, etc. (which are already eggified 
> and available on PyPI).

That sounds like a good balance to me. We need to make sure that there's 
a single Zope egg that we can version-pin that'll always have a stable, 
working set up Zope 3 packages. Zope 3 is a whole farm-full of eggs, and 
version management can be tricky. Zope 3 has a KGS, of course, so maybe 
we can just use that.

> I also started a branch of the Plone egg back then to see if it can be 
> modified to install Zope 2 completely as a dependency. See [2].

I'm pretty sure Plone 4 will want to do this. We (read: Hanno) is almost 
done eggifying all of Plone anyway.

Note that the current "Plone" egg is not maintained and never quite 
worked out. Right now we use plone.recipe.plone to install Plone in a 
buildout, which version pegs all the plone.* eggs and friends (which are 
in PyPI), and then downloads a tarball of products that are added to the 
'products' line in the generated zope.conf. We want to get rid of the 
latter, of course.

>> I would prefer a more broader approach. One of the reasons are
>> company-internals modifications to the Zope core. Right now we 
>> maintain a more or less heavy modified version of Zope 2.8 in our
>> repos (making Zope upgrades pretty hard). A better modularization
>> would help  us here. Another example:
>> the Plone people maintained a Zope 2.10 branch with experimental ZODB
>> blob support. With an eggified version of ZODB you could easily
>> switch the eggs (easily spoken).
> 
> I feel indifferent to this in general, so feel free to split away more 
> stuff from my 'Zope2' egg.

Having Zope with a separate ZODB and a few other "big" pieces makes 
sense indeed. Having tons of small packages that no-one will ever re-use 
outside a large Zope just creates overhead and the potential for people 
to buildout themselves into version conflicts.

>> So before promoting the eggification as an ultimate goal, let's discuss 
>> what we really need and want. A complete eggification just for the sake 
>> of eggs is possibly not the goal :-)
> 
> 
> [1] http://svn.zope.org/Zope2.buildout

Yay for this. :)

> [2] http://svn.plone.org/svn/plone/dist/Plone/branches/philikon-buildoutify

I'm not sure this is all that useful. For Plone 4, we're just going to 
have a number of plone.*, plone.app.* and Products.* (and a few others, 
like kss.*) eggs that we can put in a KGS or version pin in a single 
"Plone" egg.

Cheers,
Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book