[Zope-dev] package dependency refactoring progress report

[Shane Hathaway]

Martijn Faassen wrote:
> So, the only dependency cycles left in zope.app.publisher are these:
> 
> zope.app.publisher <--> zope.app.publication <--> zope.app.http

I fixed those tonight.  On the trunk, there are no longer any 
dependencies between zope.app.publisher, zope.app.publication, and 
zope.app.http, except testing dependencies.

Here is a summary of what I did:

- Moved the publication traversal code to zope.traversing and simplified 
it from 3 classes to 1.  This did not increase the dependencies of 
zope.traversing at all, since publication traversal is only slightly 
different from the traversal logic already in zope.traversing.  It also 
opens the doors for someday moving the gnarly traversal code in 
zope.publisher to something saner in zope.traversing.

- Moved an XML-RPC view registration from zope.app.publisher to 
zope.app.publication.

- Moved IHTTPException, IMethodNotAllowed, and the MethodNotAllowed 
exception class to zope.publisher.interfaces.http.  This move decoupled 
zope.app.http from zope.app.publication.

- Moved getDefaultViewName() and queryDefaultViewName() to 
zope.publisher.defaultview.  If you look at the commit messages, you'll 
see that I first attempted a different move that included the 
<browser:defaultView> handler, but that move turned out wrong for other 
packages and I reverted it.

- I used zope.deferred to deprecate things I moved from 
zope.app.publication, zope.app.publisher, and zope.app.http.  Are there 
any objections to using zope.deferred in those packages?

In all, I changed 6 packages.  Should I release them now, or should I 
look for other dependencies we might clean up at the same time?  The 
changed packages are:

zope.traversing (3.7.0)
zope.publisher (3.8.0)
zope.app.publisher (3.8.0)
zope.app.publication (3.7.0)
zope.app.http (3.6.0)
zope.app.zcmlfiles (3.5.5; bugfix only)

Shane