To construct a Zope skyscraper on Fedora

Nathaniel McCallum nathaniel at
Sun Jun 20 16:12:31 UTC 2010

On 06/20/2010 05:42 AM, Robin 'cheese' Lee wrote:
> On 06/20/2010 12:45 PM, Nathaniel McCallum wrote:
>> On 06/20/2010 12:22 AM, Jonathan Steffan wrote:
>>> On Fri, 2010-06-18 at 21:08 +0800, Robin 'cheese' Lee wrote:
>>>> The 'zope' package itself is most kept under the same conventions of the
>>>> legacy 2.10.x 'zope' package.
>>> We have a unique opportunity to address many of the failings of the
>>> current zope namespace. We should get anyone interested (and willing to
>>> do the work) into a meeting soon. Every time I go back to building up
>>> zope again I run out of steam and end up just being frustrated. I
>>> foresee issues with splitting out every module in this stack but it just
>>> needs to be discussed. The current package layout is far from optimal
>>> and it's not the best idea to ship a default standalone instance with
>>> the package. Shipping standalone/zeo instance configs/etc. in
>>> subpackages is a far better idea. I've never been able to address this
>>> as there is just about no upgrade path (that I've been able to design)
>>> that would allow for a safe re-layout of the current package.
>>> We should consider the current "zope" namespace dead and start from
>>> scratch. It's far too complex of an application to be able to have
>>> everything in one namespace (speaking to zope2 vs zope3.) I've only
>>> briefly looked into all of the specs you've worked on and already can
>>> see we are going to run into issues with cross-product dependencies. I
>>> could be convinced that the "zope" namespace should be the latest 2.x
>>> and then address the need for zope 3 in the zope3 namespace. However,
>>> how do we distinguish a module built for zope 2 vs zope 3? This, again,
>>> could be solved but will need discussion.
>>> With zope 2.12 supporting py2.6, I think we might actually have a shot
>>> at making this work. However, immediately off the bat if we stick 2.12.x
>>> into "zope" what happens to grok? What packages are going to break? Too
>>> many things need zope 2.x so updating the "zope" namespace to zope 3
>>> would break a lot of good software. What happens to plone? Do we just
>>> ditch Plone 3 and only support Plone 4?[2]
>>> We could also modularize everything and have things like "zope",
>>> "plone", "grok" and "zenoss" have dependencies based on their release
>>> recipes. There are a lot of common modules in these projects, but they
>>> all have their own specific version requirements. This would be a lot of
>>> work and could potentially cause us to package ourselves into a corner
>>> where we are having to do absolute requires or just end up with broken
>>> software when absolute requirements are not properly documented.
>>> I really look forward to others being involved with this. Count me in
>>> for the SIG.[2]
>>> - Jonathan Steffan
>>> [1]
>>> [2]
>> I agree, we've got lots to talk about.  The most important things are:
>> 1. Packaging guidelines
>> 2. Component upgrade guidelines
>> 3. Namespace issues (addressed above)
>> 4. Zope 2 vs Zope 3 (again, addressed above)
> Zope 3 seems no more going, and a new project named BlueBream[1][2]
> replacing it is being developed.
> There are also other blueprint-like and amazing projects[3][4] being
> worked on in the Zope world.
> But after all, the most productive and widely used is still Zope 2 which
> should gets higher priority.
> [1]
> [2]
> [2]
> [3]

I suspect BlueBream solves our namespace issue; namely, the zope 
namespace will be zope2 only.


More information about the devel mailing list