Hi there, Thanks Gary for sketching our the zc.async usecase. Note that zc.async isn't in the Zope Framework at this point in time so it wouldn't be directly affected by this policy, but it's still a useful usecase of course.
We seem to have a split community here... I care about this as it is more easy to see through dependency graphs and reason about circular dependencies when we don't have extra dependencies floating around, and because extras sometimes allow us to hide complicated dependency relationships (such as with zope.app.testing). Since cleaning out dependencies is such an important issue in the Framework I'd like to see less of them... So what about the following proposal then? The intent is to handle this on a case by case basis so we *shrink* the amount of extra dependencies in use within the framework. * we are going to work at getting rid of the zope.app.testing extra by distributing its facilities into individual zope.* packages. Hopefully we can get a clear consensus on this one from the people who object to the general policy. * if you think a new "extra" dependency is needed in a Zope Framework package, and you're not just moving stuff between packages but actually developing new code, bring it up on zope-dev so we can at least consider alternatives. Perhaps a better home can be found for this code. * on a case-by-case basis we can consider removing extra dependencies for particular Zope Framework packages, just like what we're doing right now for zope.component. We'll discuss that whenever needed. I'll of course be biased in favor of such removal, but I can be convinced otherwise. How do people feel about this? Note again it only applies to Framework packages, so shouldn't affect everybody. Regards, Martijn _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
