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 )
