[Zope] Serious problems upgrading to 2.1.6...

[Skip Montanaro]

I'm trying to upgrade a ZServer-only environment from 2.0.0 to 2.1.6 and am
experiencing serious problems.  I'm using the RPMs available from

    http://starship.python.net/crew/jrush/Zope/Zope216.html

I downloaded the A bundle and the zserver option from the C bundle.  I then
installed them using

    rpm -u -v -h Zope-2.1.6-1.i386.rpm Zope-zserver-2.1.6-1.i386.rpm

My main Zope server seems to have adapted to this just fine, however, I am
also running a ZServer-only setup listening on 127.0.0.2:9673 (sitting
behind an Apache proxy).  This is where I'm having trouble.

When the RPMs installed, they stuck Python modules in both /usr/share/zope
and /usr/lib/python1.5/site-packages.  My startup script finnagles sys.path
to

    ['/usr/share/zope/ZServer',
     '/usr/lib/python1.5/site-packages/DocumentTemplate',
     '/usr/share/zope/lib/python',
     '/usr/share/zope',
     '/home/dolphin/skip/cmd',
     '',
     '/usr/lib/python1.5/',
     '/usr/lib/python1.5/plat-linux2',
     '/usr/lib/python1.5/lib-tk',
     '/usr/lib/python1.5/lib-dynload',
     '/usr/lib/python1.5/site-packages',
     '/usr/local/lib/automatrix/python']

The last directory contains my application software.  In particular, it
contains the single module that gets published.  The first time I try to
access the ZServer via the proxy I get an ImportError:

    <!--
    Traceback (innermost last):
      File /usr/lib/python1.5/site-packages/ZPublisher/Publish.py, line 214, in publish_module
      File /usr/lib/python1.5/site-packages/ZPublisher/Publish.py, line 120, in publish
      File /usr/lib/python1.5/site-packages/ZPublisher/Publish.py, line 262, in get_module_info
      File /usr/local/lib/automatrix/python/z.py, line 5, in ?
      File /usr/local/lib/automatrix/python/serverdir.py, line 457, in ?
      File /usr/local/lib/automatrix/python/serverdir.py, line 366, in auto_set_identity
      File /usr/local/lib/automatrix/python/serverdir.py, line 278, in read_identity
      File /usr/local/lib/automatrix/python/musicentry.py, line 8, in ?
      File /usr/local/lib/automatrix/python/dbentry.py, line 2, in ?
      File /usr/lib/python1.5/site-packages/MySQLdb.py, line 47, in ?
      File DateTime/ISO.py, line 12, in ?
      File DateTime/Timezone.py, line 83, in ?
    ImportError: (<class exceptions.AttributeError at 8134b18>, 'DateTimeDelta')
    -->

This suggests to me that the mxDateTime module isn't being imported.  When I
try to import things manually from the interpreter prompt, I get an
ImportError for something called ts_regex:

    % pwd
    /usr/lib/python1.5/site-packages
    % python
    Python 1.5.2+ (#4, Mar 20 2000, 10:02:10)  [GCC pgcc-2.91.66 19990314 (egcs-1.1.2 release)] on linux2
    Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
    >>> from DateTime import mxDateTime
    Traceback (innermost last):
      File "<stdin>", line 1, in ?
      File "/usr/lib/python1.5/site-packages/DateTime/__init__.py", line 85, in ?
	from DateTime import DateTime
      File "/usr/lib/python1.5/site-packages/DateTime/DateTime.py", line 90, in ?
	import sys, os, math, regex, ts_regex, DateTimeZone
    ImportError: 'No module named ts_regex'

which turns out to live in the DocumentTemplate package.

It's a little bit of a miff that the RPMs install stuff in the site-packages
directory that can't stand alone, especially stuff like MAL's DateTime
package that should be able to stand alone.  As you can see from the first
traceback, I'm using DateTime via the MySQLdb module.

It's quite likely that I've screwed up my directory tree and sys.path
somehow, but I was hoping someone out there could see what I've done wrong
or what might be done to correct the damage installing the RPMs has done.
Is it safe to just reinstall MAL's DateTime package back over the busted one
that came with the RPMs?

Any feedback would be appreciated.

Thanks,

-- 
Skip Montanaro, skip@mojam.com, http://www.mojam.com/, http://www.musi-cal.com/
"We have become ... the stewards of life's continuity on earth.  We did not
ask for this role...  We may not be suited to it, but here we are."
- Stephen Jay Gould