[Python-Dev] Re: Path hacking

[James C. Ahlstrom]

Guido van Rossum wrote:
> 
> But the intention here is for the customization to be application
> specific (hence the Spam in the name).  sitecustomize doesn't know
> whethere I need the Mailman or the Knowbot root added to my path.

Ah, you have multiple scripts in one directory and multiple
Foo_path, Bar_path etc.  I was thinking with my Windows head.
A commercial Windows app generally has its own exclusive
install directory, so I was thinking single directory so a single
sitecustomize.py.

> Or do you mean to imply that we can do this with zero text added to
> the script, by simply dropping an appropriate sitecustomize.py in the
> script dir?

Yes, that is exactly what I was thinking.

> Unfortunately this does currently *not* work, because
> sys.path[0] is added after Py_Initialize() is run.

Yikes!  That kills using sitecustomize.py.  Your Spam_path
still works because it is imported later, but requires an
import in each Python main script just as you said.

Even worse, it means that exceptions.py and site.py can not
be found at all except using the normal PYTHONPATH, and
putting their path in Spam_path will *not* work.

> > >     Because the script's directory is first on the default path, the Spam
> > >     scripts will pick up Spam_path without any help from $PYTHONPATH.
> >
> > Hmmm.  Is this really true?  Nothing else, for example the registry, can
> > change sys.path[0]?  Ever?  Please say yes.
> 
> Yes.  (The registry can add module-specific paths, which will be
> searched before sys.path is even looked at, but this is only for
> specific modules.  It cannot insert a general directory that is
> searched.)  The only way this can fail is if an embedding app fails to
> call PySys_SetArgv().

Oh dear, I think I heard no instead of yes. Are you saying that if
someone else installs a Python app on my customer's machine after I do,
and sets a registry entry which sayes to use c:/other/path/to/site.py
for site.py (as he may very well want to do), then if my Python program
depends on getting my copy of site.py from my directory, it will then
use the other copy instead and may very well fail?

> In any case, that's a separate issue -- I
> agree that if sys.path[0] is '' (as it often is) it's better for
> site.py or sitecustomize.py or Spam_path.py (or whoever) to absolutize
> it (and everything else on the path) so that it will still work if the
> app does a chdir().

Point on the curve:  Windows apps generally start from an icon
which contains their path and current working directory, and
these are generally different.  So a Windows app in general will
*never* have had a getcwd() equal to the path of either the
binary interpreter or the Python main script.

> > The files exceptions.py and site.py must be in all the bin
> > directories as well as sitecustomize.py because they are
> > automatically imported in Py_Initialize().
> 
> Yes.

Well, *no* right?  This fails unless the bin directories are in
fact on PYTHONPATH.  The only way to get exceptions.py is by using
sys.path as it exists within Py_Initialize().  So there is no
hacked sys.path[0] equal to the script dir.  And since the
path hacks in site.py haven't happened yet either, we have
an incomplete sys.path at that point.

> > added to sys).  How about prepending the single directory sys.executable
> > to sys.path during Py_Initialize()?  And demanding that modules
> > like the new Greg_importer.py[c], exceptions.py[c] and site.py[c]
> > be placed there.
> 
> On Unix, this is a bin directory and it is strongly discouraged to put
> non-program files there.

Ok, point taken.

> Is the full DLL path available at any point?  This would certainly be
> a good starting point -- especially when the DLL is loaded implicitly
> as the result of some COM operation.

I don't know about loading by COM, but if it is a file, its absolute
path is reliably known in sys, the code is identical to that currently
used for sys.executable (on Windows), and I have a patch if you want.

JimA's conjecture:  It is currently impossible to
ship a Python app which can not be damaged by the installation of a
second Python app without using a hacked custom binary.

Jim Ahlstrom