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

_______________________________________________
Zope-Dev maillist  -  Zope-Dev@zope.org
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 )

Reply via email to