Roman Joost wrote:
we're doing some dependency checking at gocept and I discovered that
zope.annotation depends on in its factory.

What shall we do with this dependency to Moving this
factory to is probably not the best solution.

To be clear, zope.annotation doesn't depend on, it depends on which is its own package and egg (and in fact, zope.annotation's dependencies are refreshingly few). The real problem is that depends on a whole bunch of other things. The question is why.

Michael Howitz's email about ISite demonstrates a recurring problem:

There are several packages that do two things. One one hand they define concepts (IContained, ISite, etc.) and a little bit of machinery (contained(), getSite(), etc.) to deal with these concepts. On the other hand they also provide full-fledged implementations. Those implementations are the ones that end up introducing lots of dependencies (because they involve security, events, persistency, etc. etc.)

Perhaps it makes sense to factor the *concepts* and the light-weight helpers (contained(), getSite(), etc.) out to separate packages, e.g.:

 * zope.container
 * zope.componentsite
 * ...

There wouldn't even be a BBB problem, we could just leave import the interfaces and helpers from the new location and leave them there forever. That way, packages won't break if they still depend on and

-- -- Professional Zope documentation and training
Zope3-dev mailing list

Reply via email to