[Zope-dev] Dependencies and future of zope 3

[Tres Seaver]

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


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIvqvD+gerLs4ltQ4RAmi7AKC6IQg6lhIRIPCEtBQupDH3mx8alwCfTgOk
/JbClwZ/OalaVMdv6jYsxNI=
=+Uyq
-----END PGP SIGNATURE-----