[Zope-dev] Re: [Zope3-Users] Re: Zope 3.4.0 candidate 1 Released

[David Pratt]

Martin Aspeli wrote:

> I think you're right on the money. I really have very little idea of how 
> Zope 3 is supposed to be used right now, or what "Zope 3" really is (and 
> no-one fully agrees, as evidenced by other posts in this thread). Having 
> to piece together that information from the mailing list is pretty dire.

Hi Martin. Today, zope is a superset of functionality. We are all using 
sets of packages from this superset for our own projects in different 
ways. It may be hard for someone new to understand that you can have a 
framework by combining components and the functionality you want from a 
variety of packages (that may not packaged neatly for you). On the other 
hand, it is evolution that we are not confined by this also. In fact, it 
is analogous to python. It provides capability while you provide the 
imagination and effort to create what you want.

I believe that the folks attracted to zope seek something more from it. 
Zope's has a history of stability, scalability and innovation in python. 
While I appreciate that django, turbogears, and pylons have their own 
appeal, zope offers a mature and hardened code base with great 
strengths. This is not to say zope cannot provide a friendly and 
welcoming introduction for the python newcomer. I believe Grok provides 
this while opening the door to the potential of zope in a way that can 
simplify development.

I haven't yet seen the new documentation effort for zope but hope to 
contribute in some way to help explain what zope is today. I think Tres 
is accurate and pragmatic in his estimate of the current situation. 
Since eggs were introduced, strategies to cope with the frustration and 
growing pains encountered with eggs and setup tools had to be created.

Packaging indexes and pinning egg versions were the response to the 
changes of the last year or so. I understand the desire for continued 
releases of the monolithic zope. On the other hand I have seen the Grok 
community respond by pinning its egg versions, Jim Fulton work to 
facilitate a mirror for distributions, and Stephan assert leadership to 
create and document a system for kgs to bring sets of eggs under control.

The pattern for others working with the older monolithic zope exists in 
these examples. I believe that sets, indexes, and pinning versions 
provides the migration path for others. kgs is well documented. The 
notion of identifying versions in a buildout has been documented too. I 
believe Tres is spot on. I realize this will mean that projects using 
the old style releases with need to evolve their development and 
deployment approaches and do a bit more work to keep their eggs in 
order. In fact, this is happening all over in the python community at 
large - not just zope. I was surprised recently to see that even 
wxPython is working to eggify its releases also.

Regards,
David