To construct a Zope skyscraper on Fedora

[Nathaniel McCallum]

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] http://plone.org/documentation/faq/plone-versions
>>> [2] http://fedoraproject.org/wiki/SIGs/Zope
>>>
>> 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] http://en.wikipedia.org/wiki/BlueBream
> [2] https://launchpad.net/bluebream
> [2] http://codespeak.net/z3/five/
> [3] http://repoze.org/

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

Nathaniel