[Python-Dev] Corporate installations

[Mark Hammond]

>  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.