[Zope-dev] Dependencies and future of zope 3

[Wichert Akkerman]

Previously Tres Seaver wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Jim Fulton wrote:
> > On Sep 3, 2008, at 3:57 AM, Martin Aspeli wrote:
> >>> 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". :)
> > 
> > Only partially and only because I did something I really didn't want  
> > to do, which was to employ extras.
> > 
> > ...
> > 
> >>> 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 is a distaste for having lots of extra packages around.  
> > This isn't very important to me, but it really bugs some folks.
> 
> Extra dependencies impose burdens on every *client* of the careless pacakge:
> 
>  - Everybody has to download and store the pacakge, which wouldn't
>    be so bad for one-time use, but lots of times "rebuild the world"
>    (including blowing away caches) can be a useful strategy.
> 
>  - The cognitive load is non-trivial, even in the mythical universe
>    where every package has readable and useful documentation:  not
>    needing to consider a package's documentation is better than reading
>    it, for the case that it is truly unneeded.
> 
>  - Debugging is tougher, especially in the face of auto-included ZCML.
> 
>  - Auditing the dependent application is harder when there are not-
>    really-needed pacakges in the mix.
> 
>  - Runtime footprint issues (RAM usage, startup time) are also
>    worth onsidering.

- The chance of a conflict when one of the many packages in your project
  sees a new release increases reapidly

Wichert.

-- 
Wichert Akkerman <wichert at wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.