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