[Zope-dev] Zope Service on Windows

[Tim Peters]

[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.