[Zope-dev] Dependencies and future of zope 3

[David Pratt]

Hi Jim. Here is an idea I have that can help bring perspective and 
change. I propose that if we had the efforts of a few developers to work 
on a single reference application, and the eyes of others willing to 
inspect the package we could all benefit.

The idea would be to make the reference application as lightweight as 
possible and work backwards so that we can measure change. This would be 
a simple wsgi application. I propose we use cluemapper since it is 
simple, small and would take little time. We can create the reference 
app with different backends so we can see effect of zodb also.

The idea would be to use the reference to expose the issues, propose and 
make changes, and measure the impact of changes we are making. We also 
see how competitive we are compared to equivalent application on another 
framework in terms of no of app files, RAM consumption, no of packages, 
or other measures that would be important to developers.

We can target the dependencies from the perspective of the impact it is 
having on something real as opposed to perceived.  A second benefit is 
that we can use the application to educate folks on simple and 
lightweight zope development with wsgi.


Jim Fulton wrote:
> Some high-level remarks:
> 
> I agree with your sentiments.  I too would like to see Zope 3 technology 
> become more usable for lightweight applications.  I'd like to see the 
> existing code base evolve in that direction.
> 
> Unfortunately, Zope 3 evolved as a monolithic development tree.  
> Tendrils formed between packages that should have been independent.  
> There was no incentive to keep things cleanly separated.
> 
> I'm certain that this is fixable, but it will take a lot of work.  I 
> think this is happening slowly.  Many of us have "day jobs" and it's 
> hard to make this a priority.
> 
> Jim
> 
> 
> On Sep 2, 2008, at 8:54 PM, David Pratt wrote:
> 
>> 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
>> _______________________________________________
>> Zope-Dev maillist  -  Zope-Dev at 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 )
> 
> -- 
> Jim Fulton
> Zope Corporation
> 
> 
>