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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4