... [Martin Raspe] >>> I see the same error message that ZOPE gives.
[Tim Peters] >> FYI, pasting the exact DOS box input and output (as I did above) saves >> the reader from needing to guess at 100 details. >>> Any solution? >> Sorry, not unless someone can give useful information. If you're >> familiar with Python, you should be able to figure out why the import >> doesn't work, and tell us the solution. If you're not familiar with >> Python, it will have to wait until someone who is familiar, and can >> reproduce the problem (I cannot), does this work. [Martin] > Sorry, I thought that was clear. It says exactly the same as the ZOPE > error message: > > U:\>U:\programme\Zope-2.8.0\bin\python.exe > Python 2.3.5 (#62, Feb 8 2005, 16:23:02) [MSC v.1200 32 bit (Intel)] on > win32 > Type "help", "copyright", "credits" or "license" for more information. > >>> from ZConfig.components.logger import loghandler > Traceback (most recent call last): > File "<stdin>", line 1, in ? > ImportError: No module named components.logger > >>> Thank you -- that way we don't have to guess about anything. I note there that you did _not_ run Python while in Zope's bin\ directory, but instead ran it while in the root of your U: disk. That differs from what I did, and may be significant (although I doubt it, the current directory does play a role in setting up sys.path). > But I think I found the error: On Windows, Python seems to prefer > information from the Registry to the environment vars. No, despite popular myth, Python on Windows normally doesn't consult the registry for anything. The exception is obscure "application paths", never used in core Python, described in the near-inscrutable comment block at top of this: http://cvs.sf.net/viewcvs.py/python/python/dist/src/PC/getpathp.c?rev=1. Unfortunately, older (than build 204) versions of the pywin32 (aka win32all) extensions did set "application paths" in the registry, and Zope used to go on to install pywin32 in a broken way, causing no end of potential PYTHONPATH confusions. The Zope Windows installer does not (and never did) set "application paths" in this sense. > The wrong registry information was left there from a prior Zope/Plone > installation. Do recall exactly which registry keys seemed to be significant? > It seems the Zope-2.8.0 Windows installer does not update > the registry for Python, As above. > so Python takes a wrong import path. Since Python doesn't normally consult the registry to build sys.path, I don't think the problem is understood yet. > I found out by saying > import ZConfig > globals() > and the wrong directory would show up. I'm not clear on what you did here. Earlier you showed that you were unable to import ZConfig.components.logger. But you _were_ able to import ZConfig on its own? > Removing the old installation solved the problem. That's good -- I think <wink>. > Other Zope installations (2.7.4, 2.7.6) were not affected by the left-over > registry entries. Which registry entries, specifically? > So I suppose this is a subtle bug in the 2.8.0 Windows installer. The Zope Windows installer installs pywin32 in a very different way than it used to, and installs a very different version of pywin32 than it used to, but the zope.iss.in files (which are the input Inno Setup uses to build the installer, and which contain the code for setting Zope's registry entries) are byte-for-byte identical across 2.7 and 2.8. _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )