[Zope3-dev] cutting away dependencies
Hi there, Recently I had the opportunity to try the new buildouts of two Zope 3 projects, namely zope.tal and zope.fssync. In both, the dependency specification in install_requires looks innocent: zope.tal: 'setuptools', 'zope.i18nmessageid', 'zope.i18n', 'zope.interface', zope.fssync: setuptools', 'zope.interface', 'zope.proxy', 'zope.traversing', zope.xmlpickle' 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? It just doesn't seem needed that such basic packages pull in so much of zope. Is there a particular dependency that we could surgically alter to minimize this explosion? It'd be useful to start publishing some dependency graphs to identify critical packages. Is anyone already doing this work? Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] cutting away dependencies
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 -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
