Hi Roger. Great. I am willing to help with this. I understand the politics of change and feel there is most likely less impetus for change for those consuming packages as opposed to folks like yourself or I that use zope 3 as our framework. This is something that has to happen. The situation has gone on too long and the answer has been to exclude configuration. This is only a partial solution at best.
Roger Ineichen wrote: > Hi David > >> Betreff: [Zope-dev] Dependencies and future of zope 3 >> >> Hi there. I have been developing with zope3 for about 4 years >> and would like to see zope continue in a healthy way into the >> future. The last couple of years particularly have brought >> significant change in how we deploy zope particularly with >> wsgi with or without the zodb. In addition, there is a >> increasing plethora of lightweight frameworks emerging to >> compete with mind share and feel zope is loosing ground in >> this respect. >> >> I am feeling increasing pressure and frustration to >> re-examine what I am doing. Zope has a wonderful code base >> but it is spread through many packages in the form of >> dependencies. As a result, a small app in a working z3 setup >> can start off at almost 50MB while the similar app on a >> competitive framework may be as little as 15 - 20 MB. To some >> extent, there is complexity in the politics of change needed >> since zope is largely consumed as packages by z2 (Plone). So >> the impetus for change may be less than favorable for those >> consuming packages in Plone as opposed to a developer >> interested in creating larger scale apps purely from zope 3 >> and other python packages. >> >> The key concern is dependencies. There have been efforts I >> realize to settle some of this over the past but in reality >> the volume of zope packages that comed together for a base >> build is 'pulling in the world' >> as i have heard it referred to many times. The testing setup >> is another major factor in this and the changes controversial >> over the eliminating the testing framework as a dependency of >> zope eggs. >> >> I guess the simple solution is well it you don't like it, use >> the another framework. Its not quite that simple since I am >> extremely fond of the CA architecture and have a strong >> desire to continue with it in some form or another into the >> future. I think what I am sensing more than anything is a >> need for zope to adapt a changing reality. >> >> bfg is a relatively new framework that builds on wsgi and >> zope technologies but is an example of what can be achieved >> if you consume only what you need. It is attractive in a >> number of respects for zope developers since it offers >> simplicity and development speed with a lightweight >> footprint. I believe much of what is being accomplished in >> bfg could be accomplished in zope if it were tighter and we >> could focus on a leaner core of packages void of the large >> number of dependencies. >> The grokcore packages can help with the simplicity >> development but do little for the dependency issues. >> >> I think there are couple of options. One option would be to >> set about on a course of change to do something about this >> with the existing codebase. Another option is to create a >> core of leaner packages that could result in a much smaller, >> tighter core that can be competitive with the changing python >> landscape. bfg is currently taking the option of selectively >> forking some of the packages such as zope.catalog as >> repoze.catalog for example. Personally, I would like to see >> these changes occur in some way within zope. In any case I am >> interested in hearing from folks about what can or ought to >> be done or whether there is interest in this direction. Many thanks. > > +1 > > I fully agree. I put the dependency cleanup on my task list > and started the last couple days with reviewing the > zope core packages. > > I think everybody whould be happy if we provide less > dependencies. But if it comes to move things arround we > really have a lot of work with convince everybody. > > It whould really help if we could build a team of developers > which volunteer to review such cleanup work. That makes it > easier to make decisions and avoids that people get stocked > with their cleanup work. > > Is someone willing to help doing that task? > > Regards > Roger Ineichen > >> Regards >> David >> _______________________________________________ >> Zope-Dev maillist - Zope-Dev@zope.org >> http://mail.zope.org/mailman/listinfo/zope-dev >> ** No cross posts or HTML encoding! ** (Related lists - >> http://mail.zope.org/mailman/listinfo/zope-announce >> http://mail.zope.org/mailman/listinfo/zope ) >> > > _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
