Tim Peters wrote:
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).
On Linux I get: ['', '/home/lemburg/bin', '/home/lemburg/lib', '/home/lemburg/projects', '/home/lemburg/python/Lib/', '/home/lemburg/python/Lib/test', '/home/lemburg/python/Lib/plat-linux2', '/home/lemburg/python/Lib/lib-tk', '/home/lemburg/python/Modules', '/usr/local/lib/python1.5/site-packages'] It seems that the last entry refers to what Python thinks is the standard location for system wide extensions. The first 3 come from my PYTHONPATH setting, the next few are inserted by the Python startup code based on what Python found as landmark to determine PYTHONHOME.
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.
Sounds reasonable ;-)
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.
If Windows allows writing the process' environment you can set PYTHONCASEOK dynamically: the check queries the environment for the flag prior to every check (instead of doing going the usual internal Python flag way as many of the others do). See Python/import.c:check_case() for details. -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 77 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/