[Zope-dev] Dependencies and future of zope 3

[David Pratt]

Hi Martin. The concern is building high volume applications using z3, 
the memory footprint for virtual hosting, and the unnecessary code that 
adds to burden of managing security. **I only want the code I use**.

I agree that the current situation does not stop folks from getting 
things done but overall z3 as a development platform is looking not so 
attractive for these reasons. It is analogous to packing two suitcases 
of clothes for a trip and finding you just needed a change of underwear 
and a shirt. Frankly is just getting difficult to accept the status quo 
anymore so hoping folks can get behind this sort of effort.

I am trying to avoid the need for selective forking that Chris has found 
necessary to make progress with bfg. I want to continue using zope since 
these things are a big factor for the factors I stated.


Martin Aspeli wrote:
> 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
>