At 08:49 AM 7/10/2007 +1000, Mark Hammond wrote:
hrm - normally lib_dir is pointing at site-packages - ie, the parent of 'win32', 'win32com' etc - whereas the code above would give site-packages\win32.
Ah. Well, in the egg case, there is no win32 directory, nor win32/lib subdirectory thereof; everything that's not a package just goes right into the site-packages\pywin32-210-py2.4-win32.egg directory. If you'd like to see what's happening, download http://peak.telecommunity.com/dist/ez_setup.py and run: ez_setup.py pywin32 or alternately, install the Windows installer for setuptools, then run "python -m easy_install pywin32". At that point, you'll be able to see the site-packages layout the way it ends up under setuptools. If setuptools' directory layout is wrong in some way, let me know and I'll see what I can do.
Is there anything I can do to verify that this did in fact work correctly?
Simplest would be to paste the following 2 lines into a file:
set py = CreateObject("Python.Interpreter") WScript.Echo("1+1=" & py.Eval("1+1"))
then execute: cscript.exe //E:VBScript filename
Microsoft (R) Windows Script Host Version 5.6 Copyright (C) Microsoft Corporation 1996-2001. All rights reserved. C:\...\testfile(1, 1) (null): The specified module could not be found.
You probably would have only lost the ability to implement COM objects - consuming them should be fine. You don't get the help file registered where pythonwin can find it and don't get a bogus .pth file <wink>, but that is about it.
As it happens, the bogus .pth file gets installed inside of the pywin32*.egg directory, so it doesn't actually get read by Python. By design, easy_install wants everything for a package to be contained in its .egg, and refuses to put anything outside of it except wrapper scripts and a .pth file to put the .egg on sys.path.