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 are interesting candidates to 
look at removing as dependencies. I saw one dependency on getSite in (the rest are test dependencies)...

I wish we could separate 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 is 
in, in ZCML (see other discussion about 
zope.xmlrpcview, another reason to split this off :).

The dependency of on zope.dublincore is also 
relatively weak.



Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to