[Zope-dev] Dependencies and future of zope 3

[David Pratt]

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 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 )
>>
> 
>