To construct a Zope skyscraper on Fedora

Jonathan Steffan jon at
Sun Jun 20 04:22:40 UTC 2010

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


More information about the devel mailing list