[Zope-dev] Dependencies and future of zope 3

[Martin Aspeli]

Hi David,

David Pratt wrote:

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

Are you worried about disk space? Memory footprint?

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

zope.component, at least, is one of the packages that *does* work 
without "the world". :)

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

True. I'd say that repoze.bfg is very much part of the Zope world, 
though. It's an example of what Zope (and it's splitting of things into 
many packages) has made possible.

> It is attractive in a number of respects for zope 
> developers since it offers simplicity and development speed with a 
> lightweight footprint.

Yep. It's nice. :)

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

Reducing unneeded dependencies would indeed be a good architectural 
goal. However, I'm not sure that having a few extra packages today is 
stopping people from getting things done.

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

I'm not sure that another "armageddon" of Zope - starting it all again 
in search of something "better" - will serve anybody or go particularly 
far. I don't think that's what bfg is doing; I think it's using the 
power of Zope 3 and the CA to selectively swap out the bits it doesn't 
like for new bits. I see that as Zope delivering, not Zope failing.

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

+1, but only where it actually makes sense. I'm not sure about 
repoze.catalog... but quite often, you may get a repoze.* that's just a 
wrapper around a zope.* package to make it easier to integrate with a 
particular framework (bfg). That's the way re-use normally happens, I think.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book