Re: [Zope-dev] Re: [Zope 2.12] Eggification of Zope 2 - pros and cons?
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 ___ 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 )
Re: [Zope-dev] Re: [Zope 2.12] Eggification of Zope 2 - pros and cons?
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 ___ 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 )
Re: [Zope-dev] Re: [Zope 2.12] Eggification of Zope 2 - pros and cons?
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 <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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 )
