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
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.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -