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 _______________________________________________ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
