On Jun 15, 2007, at 12:33 PM, Martijn Faassen wrote:
These looks like dependencies that should only pull in a few more packages at most. Unfortunately this is not the case. zope.tal somehow ends up depending on, say, zope.dublincore and zope.lifecycleevent, zope.app.publisher, zope.formlib, and a total of about 60 dependencies. The story is very similar for zope.fssync. You'd not think the basic page template interpreter should have a dependency on formlib.

Do we have a plan for unweaving these dependencies?

Um. Plan ... um.  Yes, "we need to unscrew these dependencies."  :)

Seriously, we do need to work on this. Unfortunately, for years, reducing dependencies was not much of a goal due to our large "batteries included" distribution. As a result, packages became interdependent in undesireable ways.

A good example is zope.component. There's a zope.component.zcml module that basically pulls in all of Zope 3. :) We shouldn't have moved that module into zope.component. Oh well. 20/20 hindsight...

In the long run, I think we'll need to remove a lot of junk from some critical packages. We could use extras as I did in in desperation for zope.component. I don't like extras in general, but maybe they are the best way to deal with some of our historical interdependencies.


Jim Fulton                      mailto:[EMAIL PROTECTED]                Python 
CTO                             (540) 361-1714                  
Zope Corporation        http://www.zope.com             http://www.zope.org

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to