Mailing List Archive

site.py & COM startup
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).

the code I used inside site.py at line 93 looks like

if sys.prefix == '':
from imp import find_module
prefixes = [os.path.normpath(os.path.dirname(find_module('site')[1])+'/..')]
else:
prefixes = [sys.prefix]

but I guess this isn't really how it should be done. Any suggestions?
--
Robin Becker
site.py & COM startup [ In reply to ]
I typically do something like:

k_strModuleName = "swv2Phoenix"

if __name__ == "__main__":
import win32com.server.register
import sys, regsetup
# The next line is the equivalent of regsvr32 for a Python COM server.
win32com.server.register.UseCommandLine(swMapping)
# Tell the python DLL where to find this .py file
regsetup.FindRegisterModule(k_strModuleName, k_strModuleName + '.py',
sys.path)

The call into regsetup, alters the Python registry settings to register
where the .py file is located at.

Bill
site.py & COM startup [ In reply to ]
In message <4D0A23B3F74DD111ACCD00805F31D8100DB90B2B@RED-MSG-50>, Bill
Tutt <billtut@microsoft.com> writes
>I typically do something like:
>
>k_strModuleName = "swv2Phoenix"
>
>if __name__ == "__main__":
> import win32com.server.register
> import sys, regsetup
> # The next line is the equivalent of regsvr32 for a Python COM server.
> win32com.server.register.UseCommandLine(swMapping)
> # Tell the python DLL where to find this .py file
> regsetup.FindRegisterModule(k_strModuleName, k_strModuleName + '.py',
>sys.path)
>
>The call into regsetup, alters the Python registry settings to register
>where the .py file is located at.
>
>Bill
thanks that's useful
--
Robin Becker
site.py & COM startup [ In reply to ]
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.
site.py & COM startup [ In reply to ]
In article <7f0kin$ben$1@m2.c2.telstra-mm.net.au>, Mark Hammond
<MHammond@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