[Zope-dev] package dependency refactoring progress report

[Martijn Faassen]

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