Shane Hathaway wrote:
Martijn Faassen wrote:
It's interesting to see zope.deprecation is a new dependency. We could consider changing these deprecations to simple imports if this is possible...
Certainly, but what is the right way to deprecate code, then?
We've just started to do imports instead, with a BBB comment. The idea is that tools exist (or almost-exist) that can report on indirect imports; the test runner has such an extension, though I believe it's still sitting on a branch. The idea is also that plain imports are better understood by random Python programmers.
Knowing there are no cycles besides the zope.container one, this graph starts to look comprehensible, that's good. :)
It's still really big though. Hmph.
Yes. I think zope.container and zope.site are interesting candidates to look at removing as dependencies. I saw one dependency on getSite in zope.app.publisher (the rest are test dependencies)... I wish we could separate zope.site into two packages somehow. One would just contain the interfaces describing how to get to a site, and a way to easily *test* with sites, a testing module (I have some code sitting around that could help there). The other would actually implement a site in relation to containers. This work might be a good opportunity as well to think about renaming the word "site" to something else, as "site" isn't that great a word for a local component registry. The only direct dependency on zope.container (not through zope.site) is in zope.app.publisher.xmlrpc, in ZCML (see other discussion about zope.xmlrpcview, another reason to split this off :). The dependency of zope.app.pagetemplate on zope.dublincore is also relatively weak. Regards, Martijn