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