The 4 after that are a mystery, and duplicate the preceding 4 (except for meaningless-- it's Windows <wink> -- case differences).
Python makes a brave attempt to deduce the PYTHONHOME itself by looking for "well-known" files in the lib directory. Python15.dll uses argv[0] or the result of GetModuleFileName(NULL) (whichever is deemed "better" by the existance of a slash) as the basis for a search for the landmark file. If found, those 4 entries are added and if not they are added relatively (ie ".\lib" in the vain hope they will suddenly become meaningful (which they almost certainly wont) So, when running a .EXE that lives in the main Python directory (such as Python.exe), we get duplicated entries - the ones we deduced, and the ones explicitely in the registry. The problem arises when Python15.dll is used by a .exe that doesnt live in this nice directory - eg Pythonwin, or any other embedding, such as COM objects or peoples custom apps. As argv[0] and GetModuleFileName(NULL) both return a directory where "\lib" appended will not find the landmark file (string.py for windows), you get the useless relative paths added. So, what this means is that Python's strategy for deducing the PythonPath only works for Python.exe and Pythonw.exe - typically the only .exes in the Python directory. So we have the situation where the paths must also be registered in the registry if any other .exe wants to work.
I was surprised to find that setting PYTHONPATH can't be used to override any of this -- it just inserts even more stuff, into sys.path[1:1].
Once upon a time Guido stated that PYTHONPATH should override the registry completely. I cant recall the history of this tho, and wouldnt object is that was the case. You are then faced with how to set this env variable (and if you are doing that, why not just set the registry?)
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 (other common .exe's are distributed this way, so no big deal), and add a sitecustomize.py that replaces all of sys.path with the Big Four (Lib\plat-win, Lib, DLLs, and Lib\lib-tk) expressed as UNC paths, + the common Dragon dir.
This should be fine - as long as no one needs to run any other .EXE that needs Python15.dll (or unless that other .exe is also in that same directory).
Network name mangling being what it is, I suppose I'll also need to force PYTHONCASEOK. There's no way to do that from within Python, is there? If
While my views on this have temepered from illogically ranting to Guido how much I hate it, I still believe this is a mis-feature for Windows. The other alternative is to put Python.exe on the network path, and have your library in a ".\lib" directory under that. Doesnt really solve the problem for your "DragonLib" stuff - Im sure you dont want to stuff _everything_ into a single .lib directory. Also, IMO Python shouldnt bother going sniffing for its library if the registry exists. It just adds time to startup, and if it works is almost guaranteed to be redundant, and if it doesnt work will add useless entries that slow down module searches. However, that still doesnt solve your problem. The final suggestion is to put some of the win32 extensions (specifically, win32api) on a network share along with Python.exe and the standard lib. Then provide a .bat file that actually sets up the registry, and off you go. Sure, people hate the registry, but setting an environment variable is worse. Or an alternative - provide a .reg file with the necessary registry keys - users can "execute" it (double-clicking from explorer, typing the name in start->run, execute "start whatever.reg in their logon script, etc) to have their registry setup. I wish I had a better answer, but can't for the life of me work out what it should be even if MS supported it! Mark.