[PATCH] default for WSGIPythonHome

[GoogleCodeExporter]

I have linked mod_wsgi 2.3 with a custom Python in a separate prefix, but
found that sys.path is for the system Python in /usr!  Setting
WSGIPythonHome solves the problem, but I already told mod_wsgi which Python
to use at configure time.  Shouldn't it use that as a default?

Original issue reported on code.google.com by e...@pretzelnet.org on 10 Sep 2008 at 6:08

Attachments:

• diff

[GoogleCodeExporter]

When Python interpreter initialises itself, it works out where its installed 
files are by looking for 'python' executable in 
PATH and doing some relative traversals from there. If you have multiple Python 
installations on a box and the one 
you configured it to use is in a non standard location that is not in PATH for 
user Apache is started up as, it will find 
the wrong one. This can result in it simply not find files for version of 
Python it was compiled for, or if multiple 
instances of Python with same major/minor version, simply find the wrong one.

The issue of compiling in a default Python home path has been talked about 
before in the case of mod_python, but 
the open question was whether this would cause a problem in case of people who 
were packaging binary 
distributions. Namely if the Python installation they were compiling against 
wasn't actually in the same place as 
where the end user using their binary package may have Python installed.

In the discussion one person was of the belief that even if compiled in, if not 
at that location then appeared to still 
fall back to using PYTHONHOME, but this hasn't been tested properly. It may 
though be confusing for someone if 
they find they have to use WSGIPythonHome even if they have a Python at 
/usr/bin/python.

Other issue is that Python initialisation is a bit different of platforms that 
exist. Although this may work for 
Linux/Solaris etc, may not work or may cause problems on MacOS X where Python 
actually works out where it is 
installed from the location of the Python framework library it is linked to. 
That is for framework installations on 
MacOS X though, normal .so installations may work more like Linux systems.

So, accept that patch may work, but proper investigation and testing needs to 
be done to evaluate some of these 
issues.

Original comment by Graham.Dumpleton@gmail.com on 10 Sep 2008 at 6:32

[GoogleCodeExporter]

What could be done is that mod_wsgi takes that directory determined at 
configuration time and remembers it. At startup it would 
then check for existence of prefix/lib/pythonX.Y/os.py and if it exists then 
use it, else don't and rely on normal rules.

In other words, have a fail safe sanity check to avoid failure in event that 
Python is no longer at location it was when compiled.

If this isn't done and always use prefix from configuration, if Python 
installation is moved, would get an error the equivalent of:

dangermouse:~ grahamd$ PYTHONHOME=/tmp python
'import site' failed; use -v for traceback
Python 2.3.5 (#1, Mar 20 2005, 20:38:20) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> ^D

That is, 'site' module wouldn't be found.

One problem with this is that PYTHONHOME isn't necessarily a single directory. 
If sys.prefix and sys.exec_prefix are the same then it 
is one directory, but if these are different, it actually needs to list both 
directories with a separator. For this reason attached patch is 
actually not enough anyway. If fails safe idea used above, it would need to 
cope with fact that it could be two distinct directories 
and check both if needs be. In the latter, it would need to check for 
exec_prefix/lib/pythonX.Y/lib-dynload.

In other words, you are performing similar checks as in Modules/getpath.c 
contained in search_for_prefix() and search_for_exec_prefix(). This is done to 
validate whether compiled in paths would work and if not then don't use them.

This all assumes that Python layout never changes and is not customised by a 
distribution. May be better to try and somehow use 
the public functions of Python library to do the checks, but Modules/getpath.c 
is quite scary and hard to work out what could be 
used without causing problems.

Original comment by Graham.Dumpleton@gmail.com on 18 Sep 2008 at 4:25

[GoogleCodeExporter]

Decided not to do anything about this. WSGIPythonHome works, plus Apache 
startup script can also be changed 
to list location of require Python bin directory first in $PATH, if this is a 
custom setup.

The alternative as explained above is just too much of a fiddle and given that 
the instances in which it would be 
required are very small, not worth the effort.

Original comment by Graham.Dumpleton@gmail.com on 12 Mar 2009 at 5:41

• Changed state: WontFix