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.



Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to