Python is getting used widely enough in my place of employment that people are agitating for a common installation (personal variants are screwing people too often). Various machines are running Win95, Win98, NT, Windows2000, assorted flavors of Linux, Solaris, Irix and MacOS. I'll choke on that whole banana when it's shoved down my throat. For starters, I just need to get it running across Windows platforms. Never looked into this before, and it seems to be exceedingly complicated right out of the box <0.5 wink>: D:\Python>python Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
import sys ['', '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? The first is apparently the current directory; cool. The next 4 appear to come from MarkH's stuff, via the registry. The next 4 appear to come from Python's own registry PythonPath key. The 4 after that are a mystery, and duplicate the preceding 4 (except for meaningless-- it's Windows <wink> -- case differences). The last is another mystery. site.py isn't implicated in any of them (same thing when running with -S). I suppose this is a clue: D:\Python>set PYTHONHOME=ick;fooey D:\Python>python Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
import sys sys.path ['', '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', 'ick', 'fooey\\DLLs', 'ick', 'fooey\\lib', 'ick', 'fooey\\lib\\plat-win', 'ick', 'fooey\\lib\\lib-tk', 'D:\\PYTHON']
Doesn't appear to be sensible, but at least it's predictable <wink>. 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]. Do I really care? Not much -- the complexity just makes it hard to get a mental model of what Python *thinks* it's trying to accomplish here, and so harder to figure out what needs to be done. Which is pretty severe: "Dragon std" apps must run the same version of Python (which can be local) with the same libraries (which must be network-mounted), regardless of whatever version of Python each user may have built on their own, and regardless of their registry settings or envar values. 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. 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 not, everyone going through "unfortunate" paths in the network will have to set that themselves. Anyone have better ideas? That shouldn't be hard <wink>. the-difference-between-one-user-and-two-is-infinite-ly y'rs - tim