From: robin at jessikat.demon.co.uk (Robin Becker)
Date: Wed, 14 Apr 1999 02:00:26 +0100
Subject: site.py & COM startup
References: <U+ok8DAslzE3EwUd@jessikat.demon.co.uk>
 <7f0kin$ben$1@m2.c2.telstra-mm.net.au>
Message-ID: <wqzNtIAqi+E3EwhP@jessikat.demon.co.uk>
Content-Length: 1308
X-UID: 243                                                  

In article <7f0kin$ben$1 at m2.c2.telstra-mm.net.au>, Mark Hammond
<MHammond at skippinet.com.au> writes
>Robin Becker wrote in message ...
>>using Mark Hammond's win32com for a server I find that the installation
>path is not
>>automatically in sys.path so my base .pth files are missed and I get
>troubles.
>>
>>I hacked site.py to fix this using the fact that sys.prefix == '' when
>running a com
>>server (I guess inproc).
>
>It is indeed when run as an inproc.  The problem is that Python uses the
>current executable to try and deduce the Python home.  When Python is being
>used as a COM server, the host executable could be _anything_, and therefore
>cant be used to locate the Python home.
>
>So, I would like to fix this once and for all in the COM stuff, but I cant
>work out a reasonable strategy for locating the Python home.
>
>Also, FYI:  As of build 124 and later of my extensions, when you register a
>COM object its path is now also automatically saved away, and automatically
>used as the object is created - thus, no more errors due to your COM object
>not being on the PythonPath...
>
>Mark.
>
>
so the com module itself will be known, but things it might be using
aren't guaranteed if they're in the standard locations. Site.py is
supposed to be in $PYTHONHOME/Lib.
-- 
Robin Becker




