Can somebody kill getpathp for me?

[Chris Gonnerman]

----- Original Message -----
From: "Tim Peters" <tim.one at comcast.net>


> [Chris Gonnerman]
> > In the PC subdir of the Python-2.1.2 build directory is a module
> > called getpathp.c, which sets up the initial sys.path value.  It
> > is well known by Python programmers on Windows that the sys.path
> > initialization includes directories plucked from special registry
> > keys... unless you are using the PythonWare version.
>
> Or the PythonLabs distribution:  while the core installer does set up a
> registry entry containing "the usual" Python path, it *normally* never
uses
> it.  Read the long comment block at the start of getpathp.c, and this time
> believe that it means what it says <wink>.

>From several places in that comment block:

    Other "application paths" in the registry are always read.

I *don't* want this!

> Note that the core installer
> never sets up what the comment block calls "'application paths' - that is,
> sub-keys under the main PythonPath registry key".  If there aren't any
> application paths, then, as the rest of the comment block says, the main
> PythonPath key is ignored, unless a "Python Home" isn't given by a
> PYTHONHOME envar and can't be guessed from the python.exe path.

No, but win32all does (for instance).  The point is, I never want my
CD-based runtime to ever see the end user's install, if he/she has one.
The programs I want to run from CD may get psycho if the local version
has conflicting libraries, and in fact I have already encountered this
problem (so it's not just theoretical).

> > I thought, great, I can use this (the PythonWare version) to create
> > Python runnables on CD-ROM; but now I discover a fly in the ointment.
> > If the computer already has an installed Python interpreter, the
> > paths set in the registry are added, and BEFORE the paths from the
> > PythonWare PYROOT variable are added.
>
> AFAIK PythonWare doesn't ship with a custom getpathp.c, and neither does
> ActiveState, so AFAIK the comment block applies to all Python
installations.

Ah.  Didn't know that.

> The "PythonWare PYROOT variable" is news to me, google hasn't heard of it
> either, and I find no mention of PYROOT in my PythonWare PY21
installation.
> Setting a PYROOT envar has no visible effect on sys.path when I run under
> PY21 either.  That's a long-winded way of saying I think you must be
> confused <wink>.

Read the "setup.bat" file.  I assumed it actually did something... my
mistake.

> Have you tried setting PYTHONHOME?  If, e.g., I set PYTHONHOME to
\Python22,
> then execute python while *in* my \Python21 directory (these both
referring
> to PythonLabs distros), then Python 2.1.2 comes up with sys.path pointing
> entirely at Python 2.2 directories.  This is insane, but shows that
> PYTHONHOME works the way getpathp.c says it works.

Here's my result (formatting corrected, content same):

    K:\Python>set pythonhome=k:\python

    K:\Python>set path=k:\python

    K:\Python>python
    Python 2.1.1 (#20, Aug 23 2001, 11:27:17) [MSC 32 bit (Intel)] on win32
    Type "copyright", "credits" or "license" for more information.
    Alternative ReadLine 1.5 -- Copyright 2001, Chris Gonnerman
    >>> import sys
    >>> sys.path
    ['', 'C:\\Python\\win32', 'C:\\Python\\win32\\lib', 'C:\\Python',
    'C:\\Python\\Pythonwin', 'k:\\python\\DLLs', 'k:\\python\\lib',
    'k:\\python\\lib\\plat-win', 'k:\\python\\lib\\lib-tk', 'K:\\PYTHON',
    'k:\\python\\PIL', 'k:\\python\\PST', 'k:\\python\\pythonware']
    >>>

Note in particular that the Alternative Readline has been loaded.  It
shouldn't be; I didn't put it in the k:\python install, only my python.org
"standard" install on the C drive.  It seems to have already run when
site.py is loaded (I considered hacking sys.path there).

> > What I want is a version of either python.exe or python21.dll
> > (whichever contains the offending getpathp.c module) with the
> > registry-probing code disabled.
>
> If that's what you really want, you'll have to edit getpathp.c and compile
> your own Python.

It's beginning to look that way.  Dang.  That's going to be a lot of
work.  I build software with MinGW32 from time to time, but I don't have
a working CygWin install, which seems to be necessary to run the
configure script.  Frankly, no insult intended, I'd like to keep CygWin
off my computer; I tried programming with it and found it very
disappointing.

> > Ideally it should still apply the paths from PYROOT (basically in this
> > case it must).
>
> Python doesn't look at any such envar on any platform.  Maybe that's why
> setting PYROOT isn't doing you any good <wink>.  Try PYTHONHOME.

As I pointed out, I found the setup.bat file confusing; however PYTHONHOME
isn't helping either.