[Zope-dev] Dependencies and future of zope 3

[David Pratt]

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.

Regards
David