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