47 lines
1.6 KiB
Plaintext
47 lines
1.6 KiB
Plaintext
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
|
|
|
|
|
|
|
|
|