Hi, 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 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). 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 :-) Andreas
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). 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 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.
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 [2] http://svn.plone.org/svn/plone/dist/Plone/branches/philikon-buildoutify
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 :-)
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
Previously Martin Aspeli wrote:
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.
For Plone 4 we may also collapse all the plone.app.* packages in a single package. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Wichert Akkerman wrote:
Previously Martin Aspeli wrote:
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.
For Plone 4 we may also collapse all the plone.app.* packages in a single package.
+0.5 Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
Wichert Akkerman wrote:
Previously Martin Aspeli wrote:
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.
For Plone 4 we may also collapse all the plone.app.* packages in a single package.
+sys.maxint
Philipp von Weitershausen wrote:
Wichert Akkerman wrote:
Previously Martin Aspeli wrote:
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. For Plone 4 we may also collapse all the plone.app.* packages in a single package.
+sys.maxint
This is slightly off-topic here, but I think the arguments are roughly: - Single package makes it easier for the release manager: only one thing to release and test - Single package is a bit safer, lest people get their versions messed up somehow and create an incompatible environment - Multiple packages makes it a easier for people who know what they're doing to "backport" a single package into an earlier Plone version or run an experimental (develop egg/trunk) package for a time, without having to do this with the entire plone.app namespace. I suspect similar arguments would apply to Zope, except that the Zope 2 distribution is more stable than Plone's and backporting is likely to be less of an issue. Still, I've upgraded Five and ZopeTestCase more than once in the past. :) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
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).
I should add here that the 'Zope2' egg is far from finished. The things I split off (Acquisition, DateTime, ExtensionClass, etc.) are working fine by themselves, but the 'Zope2' egg needs some more attention to get its tests passing and to get it working in a production environment. I think *one* good goal of this sprint could be to switch repoze.zope2 over from using the 'zopelibs' egg to using the 'Zope2' egg. The 'Zope2' egg should still work by itself in an instance-like fashion, obviously.
On Mar 25, 2008, at 4:09 AM, Philipp von Weitershausen wrote:
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).
I should add here that the 'Zope2' egg is far from finished. The things I split off (Acquisition, DateTime, ExtensionClass, etc.) are working fine by themselves, but the 'Zope2' egg needs some more attention to get its tests passing and to get it working in a production environment.
FTR, there are things in Zope 2 (like Missing and Record IIRC) that depend on ExtensionClass (or Acquisition) headers, and there is no way to tell setuptools to depend on an external package to provide compile- time headers. We could fake it by including externals in Zope2 svn for these headers, but then there's version dependency "hidden" in these externals that will be violated if the EC and Acqusition eggs change in any given setup. There's certainly no hue and cry from the masses I've heard that EC and Acquisition be usable outside Zope 2. For this reason, I'm not entirely sure it makes sense to break Acquisition and EC out of a larger Zope 2 package. Likewise for DateTime (given that there's already a Python datetime). I suspect it would be decomposition for the sake of decomposition, which is not very compelling. There are is a similar problem between things in Zope2 and ZODB, but ZODB does have a life outside Zope2, so I think it does make sense for a Zope2 depend on an external egg for ZODB packages. - C
Chris McDonough wrote:
FTR, there are things in Zope 2 (like Missing and Record IIRC) that depend on ExtensionClass (or Acquisition) headers, and there is no way to tell setuptools to depend on an external package to provide compile-time headers. We could fake it by including externals in Zope2 svn for these headers, but then there's version dependency "hidden" in these externals that will be violated if the EC and Acqusition eggs change in any given setup. There's certainly no hue and cry from the masses I've heard that EC and Acquisition be usable outside Zope 2. For this reason, I'm not entirely sure it makes sense to break Acquisition and EC out of a larger Zope 2 package. Likewise for DateTime (given that there's already a Python datetime). I suspect it would be decomposition for the sake of decomposition, which is not very compelling.
There are is a similar problem between things in Zope2 and ZODB, but ZODB does have a life outside Zope2, so I think it does make sense for a Zope2 depend on an external egg for ZODB packages.
Likewise for Medusa. This is already packaged as an egg, we just need to delete it from ZServer. - C
Andreas Jung wrote at 2008-3-24 09:00 +0100:
... Chris favors a 'big' Zope egg with some dependencies (like ZODB) stripped out. 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.
I object that upgrades are "pretty hard" and I doubt that modularization would help in any way: Upgrades are hard only when local modifications and global ones interfere. This does not happen too often and how often it happens is independent from the modularization. -- Dieter
participants (6)
-
Andreas Jung -
Chris McDonough -
Dieter Maurer -
Martin Aspeli -
Philipp von Weitershausen -
Wichert Akkerman