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.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -