[Zope-dev] Zopeservice and sitecustomize

Tim Peters tim at zope.com
Mon Mar 8 22:27:27 EST 2004


[Sake]
> I have Zope and Activestate Python installed together in the same
> win-xp machine.  Everything works fine until I've learned that I can
> put "sys.setdefaultencoding('cp874')" into sitecustomize.py to
> accomodate my native language coding.  Since I do that, my Zope 2.7.0
> service can no longer start.  I can start it manually from
> "runzope.bat", but it never start through the windows system service.
> A full day investigation reveal that the trouble cause by the missing
> of the '<SOFTWARE_HOME>\lib\python' in the system environment's
> "PYTHONPATH". The "runzope.bat" set that up before then execution of
> "Zope.Startup.run.py", hence it run fine. But "zopeservice.py" rely on
> the "<SOFTWARE_HOME>\bin\Lib\site-packages\sitecustomize.py" to set up
> the correct "PYTHONPATH". Here is the code inside Zope's
> sitecustomize.py
>
> """ Add Zope packages in Windows binary distro to sys.path
> automagically """ import sys
> import os
> try:
>     sp = __file__
> except:
>     sp = None
> if sp:
>     dn = os.path.dirname
>     swhome = os.path.join(dn(dn(dn(dn(sp)))), 'lib', 'python')
>     if os.path.exists(swhome):
>         sys.path.insert(0, swhome)
>
> Unluckily, this sitecustomize.py is now masked with my
> sitecustomize.py inside Activestate's site-package directory, which
> actually get loaded by Zope via the Python registry load path
> (HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.3\PythonPath) instead
> of the expected one.

It's actually a different bug:  Python normally never looks at the value of
the PythonPath registry key, and that's not why your sitecustomize.py is
found first.  That's actually a side effect of ActiveState installing
win32all:  if you look *under*
HKLM\Software\Python\PythonCore\2.3\PythonPath, you'll find subkeys
Pythonwin, win32, and win32com.  It's actually the win32com subkey that puts
your ActiveState Python's lib\site-packages into sys.path.  It's then a bug
in Zope that it lets that dirty trick hide its own lib\site-packages:  Zope
ships with its own Python, and *intends* to insulate you completely (in both
directions) from whatever other Python(s) you may happen to have installed
on the machine.  So when that bug gets fixed, your sitecustomize.py will
never get executed.

BTW, sys.setdefaultencoding() is almost never a good solution; working with
Unicode instead usually is.




More information about the Zope-Dev mailing list