[Python-Dev] Corporate installations

[Tim Peters]

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