[Zope-dev] Z2 HEAD in rough shape for b/c

[Chris McDonough]

Using the HEAD with old databases and code is a real adventure these
days for these reasons:

- It doesn't start, due to a tiny config bug which I'll check a fix in
for shortly.

- Many products create instances of the class
Persistence.PersistentMapping.PersistentMapping which no longer exists
(CMFCore's SkinsTool and CMFDefault DiscussionTool are two of these). 
These things either need to be migrated somehow to
Persistence.PersistentMapping (*before*  an update to the HEAD) or we
need to provide some sort of b/c alias.  That seems tricky given the
current source layout.  I've added an alias that seems to work:

sys.modules['Persistence.PersistentMapping'] =
sys.modules['Persistence.mapping']

But this is really odd because I don't know under what circumstance this
alias shadows the effect of the line:

from Persistence.mapping import PersistentMapping

in Persistence's __init__.py module.

If there is a shadowing problem with this alias, I'd suggest we go back
to the old layout (where there really was a PersistentMapping.py module
in Persistence) on the HEAD for sanity's sake.  I'm sure there are
reasons against this, but the other option is to require every CMF/Plone
user to go through a really delicate migration before upgrading to 2.8,
which doesn't seem like a good idea.

- The HEAD apparently no longer allows URL access to methods that have
inherited function docstrings, where older versions did.  Lots of things
depend for better or worse on this behavior and this breaks a lot of
things.  They are all shallow fixes (go add a docstring, typically) but
it's  difficult to figure out where you need to go do this.

- The ZODBMountPoint product relies on a method of Connection objects
named _getMountedConnection, which apparently no longer exists.  This
breaks any mounted databases (which breaks dbtab, which breaks sessions,
which breaks lots of other things).  Hopefully this is simple to fix, I
haven't looked yet.

- ZopeVersionControl doesn't work anymore due to various ZODB changes.

- Various security declarations that used to allow access now deny.  Bug
reports don't get any more vague than that, but then again nobody's
security machinery is any more vague about reporting its reasons for
denying access than Zope's. ;-)

I can try to make headway on some of this.  Is anyone else willing to
help?

FWIW, after working through (and around) some of these issues I was able
to get Plone running on the current HEAD (well, at least plope.com,
which uses a lot of Plone), so I can happily report that Zope 2.8 isn't
100% backwards-incompatible yet. ;-)

dig-the-hole-and-fill-it-up-again'ly y'rs,

- C