Tim Peters wrote:
['', 'D:\\Python\\win32', 'D:\\Python\\win32\\lib', 'D:\\Python', 'D:\\Python\\Pythonwin', 'D:\\Python\\Lib\\plat-win', 'D:\\Python\\Lib', 'D:\\Python\\DLLs', 'D:\\Python\\Lib\\lib-tk', 'D:\\PYTHON\\DLLs', 'D:\\PYTHON\\lib', 'D:\\PYTHON\\lib\\plat-win', 'D:\\PYTHON\\lib\\lib-tk', 'D:\\PYTHON']
Where does all that stuff come from?
Good question. I don't know, and every time I start to think I do, I am wrong. Certainly PYTHONPATH is full of junk on Windows. The point is that PYTHONPATH just doesn't work for commercial installations. Please see these for some discussion: ftp://ftp.interet.com/bootmodule.html ftp://ftp.interet.com/pylib.html I think the solution is to put the library files and packages into archive files (in some format yet to be determined) and find them by looking in the directory of python15.dll and/or python.exe. On Unix there is $prefix, which actually seems to work.
I think this means I need to distribute a python15.dll and python.exe (via our source control system) into a directory very early on the PATH
Yes, that is a good start. Just understand that *.pyd and and DLL's which are imported (instead of linked against) are found from PYTHONPATH, not PATH. Also you will need a valid PATH on all PC's which is quite a bother. An alternative is to use the Wise installer to set up icons for your apps. Real Windows apps don't use PATH. We use Wise for internal as well as external apps. Note that if you import a module "import foo", and foo lives in "foo.dll", then on Windows, PYTHONPATH is searched, and the standard Windows DLL path is not searched. That means you can't use standard Windows locations for DLL's which are dynamically imported. This is an error and should be fixed.
and add a sitecustomize.py that replaces all of sys.path with the Big Four (Lib\plat-win, Lib, DLLs, and Lib\lib-tk)
The problem is that you already need a valid PYTHONPATH to find sitecustomize.py. Better is to create a custom python15.dll with sitecustomize.py, exceptions.py and site.py (all needed during boot) frozen in as frozen modules. In our office I freeze in other library files too.
Network name mangling being what it is, I suppose I'll also need to force PYTHONCASEOK.
I don't seem to need that on 95/98/NT. Network names shouldn't get mangled on these systems. I guess you mean lack of case sensitivity, but just make sure the case is correct in the Lib directory. This is another reason to prefer archive files anyway. But no, you shouldn't need PYTHONCASEOK.
Anyone have better ideas? That shouldn't be hard <wink>.
Yes, this is a major problem with Python's acceptance for commercial apps (and I include internal production code as an app) so lets figure out what to do and fix it. Jim Ahlstrom