[Christian Theune]
I just checked in how I finally got Zope 2.7.x to run as a service on Windows again. Setting the PYTHONPATH environment actually even makes more sense here as the CreateProcess API call won't take the sys.path into the new python, but the environment variables.
It doesn't sound like a good solution. PYTHONPATH is Python's envar, not Zope's, and a user can legitimately set PYTHONPATH to whatever they like (for example, to get other extensions they've installed found by whichever Python is running). Then their stuff won't work if we clobber their PYTHONPATH.
This now also plays with the import of sitecustomize.py correctly.
I still wonder why this seems to behave differently in 2.7 as in 2.8. The 2.8 currently works as a service out of the box. I don't see the actual difference. Anybody tell me. I'm scared.
I don't know -- I've lost track of how Zope 2 gets built on Windows. All along on Windows, Products/WinBuilders/etc/ has tried to install its own sitecustomize.py on Windows, to force the software home into sys.path whenever Zope's Python is used. I don't have any idea how that plays with "the other" sitecustomize.py newly added to Zope 2 proper. Best guess is that they conflict horribly <wink>, but that nobody has noticed that yet.
Also: I'd like to know if this solution for 2.7 is acceptible or not. It works for me but I'm everything but a windows guru.
As above, I doubt it's the right solution. But if nobody on Windows complains, maybe you're stuck with it. It would be good to know if you're aware of WinBuilders and Zope fighting over sitecustomize.py now. Who wins? If Zope's sitecustomize.py is overwriting the sitecustomize.py WinBuilders tries to install, that would explain why Windows services stopped working.