[mod_python] patch to use Py_SetProgramName()

On 28/03/2008, Glen W. Mabey <Glen.Mabey at swri.org> wrote:
> On Wed, Mar 26, 2008 at 03:51:58PM -0500, Graham Dumpleton wrote:
>  > Even if it fixes things on some platforms, the problem I have with it
>  > is that it hard codes a path into the executable. If the 'python'
>  > executable supplied to --with-python was actually a symlink to another
>  > location, the result will be an incorrect location is used as you
>  > really want the location pointed at, not where the symlink was.
>  > Another problem might be where people building binary distributions of
>  > mod_python use some special Python installation not in the standard
>  > location. It may work for them when they test it, but when they
>  > release it it then make break for others because they may not have
>  > Python installed where person who built it did.
>
>
> My impression from the description of the Py_SetProgramName() function
>  was that it provided not so much of a hard-coding to the path but rather
>  steering the search for the executable to first look at a specific
>  location before looking in other likely places.

You are probably right, been a while since I looked at Python
internals for that stuff.

>  Has that been your experience in using Py_SetProgramName()?

What I do know is the code in Python internals which uses that value
and others such as PYTHONHOME is really convoluted, especially when it
comes to Windows and MacOS X where I never did quite work out where it
finds some stuff for determining prefix location.

>  > What was found with mod_wsgi was that it was better to have a
>  > directive in Apache configuration file which allowed one to set
>  > PYTHONHOME.
>
> Apparently, the use of PYTHONHOME would still override the value given
>  to Py_SetProgramName(), so it doesn't seem to me that you would lose any
>  flexibility by its use.

I'll give it some more thought, setting it may not be such a big deal,
I was perhaps just being overly cautious as I wanted something that
would work cross platform.

What I definitely don't want to do again is expose a
WSGIPythonExecutable directive as it just caused confusion as people
were using it for virtual environments when they should have been
using WSGIPythonHome. It became an issue because people were blogging
examples using WSGIPythonExecutable but then it wouldn't work on
Windows or MacOS X.

Graham

>  > This still didn't work for Windows, but seemed the best
>  > compromise. One benefit of making it configurable through the Apache
>  > configuration file was that that mechanism could then be used to point
>  > the interpreter at a Python virtual environment isolated from
>  > site-packages of standard Python installation. For details on this
>  > see:
>  >
>  >   http://code.google.com/p/modwsgi/wiki/VirtualEnvironments
>  >
>  > You might also read section 'Multiple Python Versions' of:
>  >
>  >   http://code.google.com/p/modwsgi/wiki/InstallationIssues
>  >
>  > which for mod_wsgi talks about the same problem with wrong version of
>  > Python being found.
>
>
> One reason for my terseness in my original post was that I couldn't see
>  any reason (at the time) for not employing Py_SetProgramName(), since it
>  seemed to me to be the preferred mechanism (if the executable path is
>  known at compile time) to *correctly* specify the path for a package
>  maintainer whose work will end up on other people's systems.  Or to give a
>  person like myself (targeting a specialized type of installation) to use
>  a symlink that actually points to the desired interpreter, without the
>  need to define PYTHONHOME (that has complicated things in the past
>  here).
>
>  Anyway, thank you for you attention.
>
>
>  Glen Mabey
>