[Python-Dev] Re: Path hacking

[Guido van Rossum]

[me]
> > 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.

[JimA]
> 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.

Not too bad (who cares about one more line of boilerplate...).

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

Why would you want your own exceptions.py and site.py?

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

Again - why would anyone register their own site.py?

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

You're lucky.  It turns out that on Windows, under those circumstances
at least, sys.path[0] is the absolute pathname of the directory.  You
only see '' if sys.argv[0] doesn't have any pathname information;
that's only possible if the script *does* live in the current
directory.

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

Sorry, I've lost track of what we were after here.  Indeed the
scripts' directory (which I presume you meant by the bin directory)
indeed doesn't occur in sys.path until after Py_Initialize() has run.

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

I presume using GetModuleFileName()?  Please send me the patch!

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

Sounds right.  All tricks to make the app unique require using a
different registry key, which requires a change to the DLL.  However,
you can do this without recompiling!  The version string is used is
embedded in a resource, so you can patch it using some kind of
resource editor.  Mark Hammond planned it this way!

--Guido van Rossum (home page: http://www.python.org/~guido/)