[Python-Dev] Re: [Distutils] Questions about distutils strategy

[Tim Peters]

[Skip Montanaro]
> Alright!  Now I understand what all the hubbub is about!  My eyes have
> mostly been glazing over trying to follow all this Windows
> registry/path/ini stuff.  MS believes that Python is the application.
> Those of us writing Python programs view those programs as the
> applications, not the Python interpreter per se.

Eww -- that's a helpful and insightful way to put it, Skip!  Now maybe *I*
can understand what the hubbub is about <wink>.

> Is there some way that people writing applications in Python can set
> up registry entries that are specific to their application (e.g.
> tabnanny.py) instead of only specific to the Python interpreter?

Yes, but they can't get Python to look at those before it's too late.  I
spent a whole evening a month or two ago just trying to figure out where all
the cruft in my Windows sys.path *came* from.  This is out-of-the-box; I
haven't added anything myself:

['',
 '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']

That's bizarre on the face of it, and tracking it all down was draining.
I've forgotten the details.  I do remember concluding that it was impossible
to do what I wanted to do without changing the implementation, though, and
nobody on Python-Dev disputed that at the time.

In a pragmatic crunch, I wrote the little app I needed to distribute at the
time in Perl instead, meaning to come back to this.  I haven't had time.

IIRC, the ultimate problem wasn't really that Python looked at the registry
to get *some* path info, it was a combination of

A) It looked at the registry so early that it was impossible to stop it from
executing whatever site.py the registry pointed at (well, I could with
the -S option -- but then there was no way to get it to do the site.py that
was *wanted* instead).

B) No way to override what was in the registry; e.g., I was greatly
surprised to discover that setting a PYTHONPATH envar didn't override
anything, it simply plunked the PYTHONPATH entries into sys.path along with
everything else -- and too late to stop anything anyway.

In a long msg I haven't yet read all the way thru, Guido at least suggested
associating different registry path info with different Python versions.
That would address a number of otherwise currently intractable problems.

I suspect it still wouldn't help with the problem I was facing, though.
That is, I wanted to be able to tell people to run

\\dragres01\mrec\reduce\python \\dragres01\mrec\reduce\reduce.py

which is just a Windows way of saying "run a Python executable from a shared
network location".  When they tried that, though, the network Python looked
in *their* individual registries for its Python path info, and some of the
hackers with mondo customized Python setups on their own machines watched
things go down in flames.

This certainly can't be a common problem, but it speaks to an unforgiving
rigidity in the current approach.  There seemed to be nothing I could do to
guarantee this would work, short of telling users to edit their registries
before running this tool (that's a non-starter on Windows -- editing the
registry is dangerous) or putting a customized Python on the network
pointing to a bogus registry key (it was faster to write the app in Perl!
Perl doesn't *try* to be so infernally helpful <wink>, so doesn't get in the
way either).

I'm left wondering what purpose putting Python library path info into the
Windows registry serves.  Is there anyone on Windows who *doesn't* have
their Python Lib/ etc as direct subdirectories of the directory containing
python.exe?  Not that I've seen.  Python puts *those* in sys.path too -- but
only after it (in the normal case; see my sys.path above) pulls identically
redundant paths out of the registry first, or (in the cases we're griping
about) pulls irrelevant or downright harmful paths out of the registry first
(paths appropriate to the last Python you *installed*, not to the Python
that's *running*!).

Perhaps all this cruft is needed to support embedded Python, though
(something I've never done).

Regardless, I expect it would have been enough for me if PYTHONPATH simply
worked the way I mistakenly assumed it would (that is, this is sys.path, and
that's *it*; feel free to prepend the current directory when initialization
is complete, but before then looking at any file not reached from PYTHONPATH
is verboten).

the-cleverer-the-code-the-more-vital-that-there-be-a-way-to-
    short-circuit-it-ly y'rs  - tim