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.
> 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?
> Roger Ineichen
>> Zope-Dev maillist - Zope-Dev@zope.org
>> ** No cross posts or HTML encoding! ** (Related lists -
>> http://mail.zope.org/mailman/listinfo/zope )
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -