WSGIPythonHome ignored under Windows

[Clemens Hermann]

Hi all,

Graham, first I want to thank you for writing mod_wsgi.
However, my first installation attempt was not successful.

I created a virtualenv sandbox as described in
http://code.google.com/p/modwsgi/wiki/VirtualEnvironments but

WSGIPythonHome C:\pythonenv\BASELINE

seems to be ignored. the statement is located directly beneath the
DocumentRoot directive.

[Tue Jan 15 16:48:57 2008] [notice] Apache/2.2.6 (Win32) mod_wsgi/1.3
Python/2.5.1 configured -- resuming normal operations
[Tue Jan 15 16:48:57 2008] [notice] Server built: Sep 5 2007 08:58:56
[Tue Jan 15 16:48:57 2008] [notice] Parent: Created child process 4348
[Tue Jan 15 16:48:57 2008] [warn] mod_wsgi: Compiled for Python/2.5.
[Tue Jan 15 16:48:57 2008] [warn] mod_wsgi: Runtime using Python/
2.5.1.
[Tue Jan 15 16:48:57 2008] [warn] mod_wsgi: Python module path 'C:\
\WINDOWS\\system32\\python25.zip;C:\\Python25\\Lib;C:\\Python25\
\DLLs;C:\\Python25\\Lib\\lib-tk;;C:\\Program Files\\Apache Software
Foundation\\Apache2.2\\bin'.

as you see the Python module path is not the one specified in
WSGIPythonHome

I used the windows module from http://adal.chiriliuc.com/mod_wsgi/.

thanks a lot in advance for any hint,

/ch

[gert]

could it be you actualy want
WSGIPythonPath "C:/pythonenv/BASELINE"
instead of WSGIPythonHome

->remember always use / forward slash <-

[Graham Dumpleton]

I'm not sure anyone has confirmed for me that WSGIPythonHome actually
works on Windows. Windows does strange things.

The use of a single backward slash could be an issue as gert pointed
out, although to follow what Python possible expects, may need to be:

WSGIPythonHome C:\\pythonenv\\BASELINE

Even if that were the problem, if Python was paying attention to it,
it would most likely have died rather than fallback to some default
calculated from where the Windows registry.

Maybe Adal can comment, as I am not a Windows person.

Graham

[Clemens Hermann]

Gert and Graham,

thanks for your replies.

neither the insertion of WSGIPythonPath, nor double backslashes in the
path made any difference.

regards,

/ch

[Graham Dumpleton]

On 16/01/2008, Clemens Hermann <clh...@googlemail.com> wrote:
>

Use of WSGIPythonHome was only if you wanted to create a base line
Python which was isolated from your standard installed version. This
was always optional, and as long as there are no conflicting package
requirements with your virtual environment you don't need to use it.
So, just use site.addsitedir() or WSGIPythonPath as appropriate for
the version of mod_wsgi and should all still work anyway.

Graham

[Clemens Hermann]

On Jan 16, 12:33 pm, "Graham Dumpleton" <graham.dumple...@gmail.com>
wrote:

>
> Use of WSGIPythonHome was only if you wanted to create a base line
> Python which was isolated from your standard installed version.

that's exactly what I am trying to accomplish.

regards,

/ch

[gert]

i am trying the Home thing my self, but can you confirm
WSGIPythonPath works first please ?

So i know it has nothing to do with forward slashes or something
WSGIPythonPath from 2.0c4 works fine on vista.

I am currently stuck at part one making a virtual env If you could
help me with that so i can try it too :)

[Adal Chiriliuc]

WSGIPythonHome does work on Windows.

See this message with details:
http://groups.google.co.uk/group/modwsgi/msg/696e46ef3a3a2bdf

As for the Virtual Environments instructions, it looks like it was not
tested on Windows, so it may need some tweaks. For the record, I do
have multiple environments for my own projects, but I use .pth files
to switch between them.

Sample:

SP.pth
======
D:\Projects\SP\Python

Anim.pth
=======
D:\Projects\Anim\Python
D:\Projects\Anim\Website\AnimWeb
import site; site.addsitedir(r"D:\Projects\Anim\Vendor\PythonLib")

The .pth files live in the folder with python.exe. When I want to work
on one project, I just rename the other .pth files to .pth1. Not very
elegant but works for me.

> I used the windows module fromhttp://adal.chiriliuc.com/mod_wsgi/.

[Graham Dumpleton]

On 17/01/2008, Adal Chiriliuc <adal.ch...@gmail.com> wrote:
>
> WSGIPythonHome does work on Windows.
>
> See this message with details:
> http://groups.google.co.uk/group/modwsgi/msg/696e46ef3a3a2bdf
>
> As for the Virtual Environments instructions, it looks like it was not
> tested on Windows, so it may need some tweaks.

That is because I rely on you to test things on Windows for me. ;-)

If you get a chance and can work out what is wrong with the
instructions and let me know, would be much appreciated.

Graham

[Adal Chiriliuc]

I didn't know that you wrote the instructions, just noticed :-)

I'll test them and see if they work or how to fix them for Windows.

On Jan 17, 2:54 am, "Graham Dumpleton" <graham.dumple...@gmail.com>
wrote:

[Clemens Hermann]

On Jan 17, 1:54 am, "Graham Dumpleton" <graham.dumple...@gmail.com>
wrote:
>

> > As for the Virtual Environments instructions, it looks like it was not
> > tested on Windows, so it may need some tweaks.
>

> If you get a chance and can work out what is wrong with the
> instructions and let me know, would be much appreciated.

I further investigated the issue and it seems not to be related to
Virtual Environments in the first place.

the root cause here is still that WSGIPythonHome is completely
ignored. WSGIPythonPath in contrast is respected and appended to the
existing sys.path.

Besides PYTHONPATH and PYTHONHOME on Windows sys.path (and probably
also Py_GetPath) additionally adheres to the registry key
"HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.5\PythonPath" which
gets set by the Python Windows installer.
Any of those are accepted from mod_wsgi. Just WSGIPythonHome is
constantly ignored, no matter which of the former are set or cleared.

I copied C:\Python25 to C:\Python25_2 to make sure its not something
inside the Python directory that causes the problem.

Btw, to make sure I am not trapped by a slash, backslash, doubleslash
or quote thing I tried all of these:

WSGIPythonHome "C:\Python25_2"
WSGIPythonHome "C:/Python25_2"
WSGIPythonHome "C:\\Python25_2"
WSGIPythonHome "C://Python25_2"
WSGIPythonHome C:\Python25_2
WSGIPythonHome C:/Python25_2
WSGIPythonHome C:\\Python25_2
WSGIPythonHome C://Python25_2

Adal, in http://groups.google.co.uk/group/modwsgi/msg/696e46ef3a3a2bdf
you reported success in using WSGIPythonHome. Could you check again to
make sure the path does not creep into your sys.path through one of
the other options mentioned?
Could you also check if it works with the original Installer from
python.org? In your post it seems like you are using a self compiled
version which e.g. might lack the registry key supplied by the python
installer.

best regards,

/ch

[Graham Dumpleton]

Does the directory you are setting WSGIPythonHome to contain:

lib\\os.py

and can you actually give a list of what is in the directory?

According to PC/getpathp.c in Python source code, it does supposedly
still take PYTHON_HOME into account, but hard to work out what the
code is actually doing.

Graham

[Graham Dumpleton]

> still take PYTHONHOME into account, but hard to work out what the
> code is actually doing.

It seems that PYTHONHOME has a totally different meaning on Windows
than UNIX boxes. On Windows it seems the only thing it is used for is
to resolve where relative URLs in PYTHONPATH are rooted at.

if (p[0] == '.' && is_sep(p[1])) {
strcpy(buf, pythonhome);
buf = strchr(buf, '\0');
p++;
n--;
}

It would also seem on Windows that everything is based off where the
Python DLL is located and that cannot be overridden through
configuration that mod_wsgi could set.

My question then is, in a Windows virtualenv, does it copy into the
virtualenv the Python DLL? If it does, the alternative to
WSGIPythonHome on Windows is probably to ensure that the Apache
service is started up with PATH with the directory the virtualenv
Python DLL is located in being before anything else. Presuming that is
that searching PATH is how it is found in the first place.

Windows people please help me here. How does one make Apache see the
Python DLL in the virtualenv first?

Graham

[Adal Chiriliuc]

I'm halfway in the test of virtualenv. I'm at the point where I have
installed Pylons and now I need to create a Pylons app.

I don't have the file with the exact instructions I have followed
available right now, but there is a documentation problem (in the
virtualenv documentation, not yours). It says there that even on
windows you need to run /virtualenv/PYLONS-1/bin/activate.bat. The
problem is that there is no bin folder in the created environment.
The .bat and .exe files (activate.bat, easyinstall.exe, ...) are
located in a Scripts folder. But besides this, everything worked (the
pylons eggs where installed in the PYLONS-1 folder).

To be clear: there are no pythonXX.[dll|exe] files on windows in the
BASELINE or PYLONS-1 folder.

The testing was done in a Windows XP virtual machine with almost
nothing installed. Python.exe was NOT in PATH, since the Python
installer does not add it there and I didn't want to do anything else
besides installing Python. python25.dll however is in PATH since the
installer puts it into the C:\Windows\System32 folder (a bad idea in
my opinion).

> It would also seem on Windows that everything is based off where the
> Python DLL is located and that cannot be overridden through
> configuration that mod_wsgi could set.

I'm 90% sure I didn't make an error in my test of WSGIPythonHome which
showed that it didn't matter where pythonXX.dll is located. I'll test
this evening the other 10% ;-)

On 18 Jan, 03:45, "Graham Dumpleton" <graham.dumple...@gmail.com>
wrote:

> > > Adal, inhttp://groups.google.co.uk/group/modwsgi/msg/696e46ef3a3a2bdf

[Clemens Hermann]

On Jan 18, 2:25 am, "Graham Dumpleton" <graham.dumple...@gmail.com>
wrote:
>

> Does the directory you are setting WSGIPythonHome to contain:
>
>   lib\\os.py

yes

> and can you actually give a list of what is in the directory?

Directory of C:\webapps\BASELINE

01/15/2008 04:37 PM <DIR> .
01/15/2008 04:37 PM <DIR> ..
01/15/2008 03:56 PM <DIR> Lib
01/15/2008 03:56 PM <DIR> Scripts

Directory of C:\webapps\BASELINE\Lib

01/15/2008 03:56 PM <DIR> .
01/15/2008 03:56 PM <DIR> ..
12/12/2006 05:20 PM 34,331 codecs.py
10/29/2007 09:30 AM 33,651 codecs.pyc
07/02/2007 12:07 PM 33,651 codecs.pyo
04/03/2006 12:45 PM 6,929 copy_reg.py
10/29/2007 09:30 AM 5,091 copy_reg.pyc
07/02/2007 12:07 PM 5,045 copy_reg.pyo
01/15/2008 03:56 PM <DIR> distutils
01/15/2008 03:56 PM <DIR> encodings
10/28/2005 07:07 PM 3,126 fnmatch.py
10/29/2007 09:30 AM 3,234 fnmatch.pyc
09/13/2007 09:45 AM 3,234 fnmatch.pyo
05/26/2006 12:23 PM 74,614 locale.py
10/29/2007 09:30 AM 43,801 locale.pyc
07/02/2007 12:07 PM 43,801 locale.pyo
01/15/2008 03:56 PM 0 no-global-site-packages.txt
04/26/2006 02:21 PM 17,087 ntpath.py
10/29/2007 09:30 AM 11,957 ntpath.pyc
07/02/2007 12:07 PM 11,910 ntpath.pyo
01/15/2008 03:56 PM 11 orig-prefix.txt
12/12/2006 05:20 PM 25,405 os.py
10/29/2007 09:30 AM 24,557 os.pyc
07/02/2007 12:07 PM 24,557 os.pyo
10/17/2006 04:19 PM 14,228 posixpath.py
10/29/2007 09:30 AM 12,259 posixpath.pyc
03/23/2006 07:56 PM 12,547 re.py
10/29/2007 09:30 AM 12,335 re.pyc
07/02/2007 12:07 PM 12,335 re.pyo
01/15/2008 03:56 PM <DIR> site-packages
01/15/2008 03:56 PM 15,675 site.py
01/15/2008 03:56 PM 15,703 site.pyc
04/04/2007 05:17 PM 397 sre.py
10/28/2005 07:07 PM 17,031 sre_compile.py
10/29/2007 09:30 AM 11,406 sre_compile.pyc
07/02/2007 12:07 PM 11,293 sre_compile.pyo
10/28/2005 07:07 PM 7,398 sre_constants.py
10/29/2007 09:30 AM 6,120 sre_constants.pyc
07/02/2007 12:07 PM 6,120 sre_constants.pyo
10/28/2005 07:07 PM 27,679 sre_parse.py
10/29/2007 09:30 AM 19,704 sre_parse.pyc
07/02/2007 12:07 PM 19,704 sre_parse.pyo
10/28/2005 07:07 PM 1,753 stat.py
10/29/2007 09:30 AM 2,394 stat.pyc
07/02/2007 12:07 PM 2,394 stat.pyo
08/03/2006 08:27 AM 2,643 types.py
10/29/2007 09:30 AM 2,688 types.pyc
07/02/2007 12:07 PM 2,688 types.pyo
03/06/2006 03:19 PM 5,904 UserDict.py
10/29/2007 09:30 AM 8,637 UserDict.pyc
07/02/2007 12:07 PM 8,637 UserDict.pyo

Directory of C:\webapps\BASELINE\Scripts

01/15/2008 03:56 PM <DIR> .
01/15/2008 03:56 PM <DIR> ..
01/15/2008 03:56 PM 406 activate.bat
01/15/2008 03:56 PM 204 deactivate.bat
01/15/2008 03:56 PM 325 easy_install-2.5-script.py
01/15/2008 03:56 PM 6,656 easy_install-2.5.exe
01/15/2008 03:56 PM 317 easy_install-script.py
01/15/2008 03:56 PM 6,656 easy_install.exe
01/15/2008 03:56 PM 24,064 python.exe

[Adal Chiriliuc]

I tested the virtualenv instructions and they work. A very detailed
descriptions of the steps I took follows:

1. Installed Python 2.5.1 with default options

NOTE: C:\Python25 and C:\Python25\Scripts folders are NOT in PATH
(the installer does not add these folders to PATH).

2. Installed setuptools-0.6c7 using ez_setup.py
3. Installed virtualenv
4. Created C:\PythonEnv
5. cd C:\PythonEnv
6. C:\Python25\Scripts\virtualenv.exe --no-site-packages BASELINE

App 1
=====
1. cd C:\PythonEnv
2. C:\Python25\Scripts\virtualenv.exe --no-site-packages PYLONS-1
3. Run C:\PythonEnv\PYLONS-1\Scripts\activate.bat (not PYLONS-1\bin
\activate.bat, no bin folder here) in a command line prompt
3.1. easy_install Pylons
3.2. cd C:\PythonEnv\PYLONS-1
3.3. paster create -t pylons one
7. Create PYLONS-1\serve.bat with content:
@cd one
@paster serve --reload development.ini
8. Run PYLONS-1\serve.bat (from inside the activated command prompt)
9. Tested http:/127.0.0.1:5000 - everything OK
10. Created C:/PythonEnv/PYLONS-1/one/one.wsgi with content:

##########################

# Differences from the http://code.google.com/p/modwsgi/wiki/VirtualEnvironments
indications:
# /lib/site-packages versus /lib/python2.5/site-packages (/
python2.5/ component missing)
# no PYTHON_EGG_CACHE environment variable (not clear to me if this
is needed on Windows)

import site
site.addsitedir('C:/PythonEnv/PYLONS-1/lib/site-packages')

import os, sys
sys.path.append('C:/PythonEnv/PYLONS-1/one')

from paste.deploy import loadapp
application = loadapp('config:C:/PythonEnv/PYLONS-1/one/
development.ini')

##########################

App 2
=====
1. The same as above, except using PYLONS-2 and "two" for the Pylons
app name

Web Server
==========
1. Copied Apache-2.2.4 files to C:\PythonEnv\Apache-2.2.4
- The files were taken from a previous installation. You can
install Apache, probably nothing will change.
2. Started Apache (C:\PythonEnv\Apache-2.2.4\bin\httpd.exe) -
everything OK
3. Copied mod_wsgi.so (2.0c4) to C:\PythonEnv\modwsgi-2.0c4
4. Added to C:\PythonEnv\Apache-2.2.4\conf\httpd.conf:

##########################

LoadModule wsgi_module C:/PythonEnv/modwsgi-2.0c4/mod_wsgi.so

WSGIPythonHome C:/PythonEnv/BASELINE

<Directory C:/PythonEnv/PYLONS-1/one>
Order allow,deny
Allow from all
</Directory>

<Directory C:/PythonEnv/PYLONS-2/two>
Order allow,deny
Allow from all
</Directory>

#WSGIScriptAlias / C:/PythonEnv/PYLONS-1/one/one.wsgi
#WSGIScriptAlias / C:/PythonEnv/PYLONS-2/two/two.wsgi

##########################

Depending on which WSGIScriptAlias directive is uncommented the
corresponding WSGI application will be runned. I've checked and it
works correctly.

The good thing is that the VirtualEnvironments instructions work.
However you need to be careful to the details.

One thing easy to get wrong: it's not enough to double-click
activate.bat in Explorer. It will do absolutly nothing since the only
way to permanently set PATH in Windows is either by using System from
Control Panel or directly setting them in the registry (like a script
I have does). The correct way to use activate.bat is this: start a
command line prompt, change directory to the folder containing
activate.bat, run it, and then do the additional operations (like
paster create -t pylons my_app) FROM THIS COMMAND LINE PROMPT. This is
kind of annoying (if you don't use a file manager like Altap
Salamander ;)

WSGIPythonHome
==============
From the Apache log:

[warn] mod_wsgi: Compiled for Python/2.5.

[warn] mod_wsgi: Runtime using Python/2.5.1.

[warn] mod_wsgi: Python module path 'C:\\WINDOWS\\system32\
\python25.zip;C:\\Python25\\Lib;C:\\Python25\\DLLs;C:\\Python25\\Lib\

\lib-tk;;C:\\PythonEnv\\Apache-2.2.4\\bin'.
[notice] Apache/2.2.4 (Win32) mod_wsgi/2.0c4 Python/2.5.1 configured
-- resuming normal operations
[notice] Server built: Jan 9 2007 23:17:20
[notice] Parent: Created child process 3948

Notice that C:/PythonEnv/BASELINE doesn't appear anywhere. The correct
application is served even if the WSGIPythonHome directive is
commented out.

I have logged sys.path at the end of one.wsgi. I get the same paths
with/without WSGIPythonHome:

C:\Python25\lib\site-packages\setuptools-0.6c7-py2.5.egg
C:\Python25\lib\site-packages\virtualenv-1.0-py2.5.egg
C:\PythonEnv\PYLONS-1\lib\site-packages\setuptools-0.6c7-py2.5.egg
C:\PythonEnv\PYLONS-1\lib\site-packages\pylons-0.9.6.1-py2.5.egg
C:\PythonEnv\PYLONS-1\lib\site-packages\mako-0.1.8-py2.5.egg
C:\PythonEnv\PYLONS-1\lib\site-packages\nose-0.10.1-py2.5.egg
C:\PythonEnv\PYLONS-1\lib\site-packages\decorator-2.2.0-py2.5.egg
C:\PythonEnv\PYLONS-1\lib\site-packages\simplejson-1.7.1-py2.5.egg
C:\PythonEnv\PYLONS-1\lib\site-packages\formencode-0.7.1-py2.5.egg
C:\PythonEnv\PYLONS-1\lib\site-packages\pastescript-1.3.6-py2.5.egg
C:\PythonEnv\PYLONS-1\lib\site-packages\pastedeploy-1.3.1-py2.5.egg
C:\PythonEnv\PYLONS-1\lib\site-packages\paste-1.4.2-py2.5.egg
C:\PythonEnv\PYLONS-1\lib\site-packages\beaker-0.7.5-py2.5.egg
C:\PythonEnv\PYLONS-1\lib\site-packages\webhelpers-0.3.2-py2.5.egg
C:\PythonEnv\PYLONS-1\lib\site-packages\routes-1.7.1-py2.5.egg

C:\WINDOWS\system32\python25.zip
C:\Python25\Lib
C:\Python25\DLLs
C:\Python25\Lib\lib-tk

C:\PythonEnv\Apache-2.2.4\bin
C:\Python25
C:\Python25\lib\site-packages
C:\PythonEnv\PYLONS-1\lib\site-packages
C:/PythonEnv/PYLONS-1/one

I will redo the WSGIPythonHome directive tests tomorrow.

[Graham Dumpleton]

>> It seems thatPYTHONHOMEhas a totally different meaning onWindows
>> than UNIX boxes. OnWindowsit seems the only thing it is used for is

>> to resolve where relative URLs in PYTHONPATH are rooted at.
>>
>

> Not true.  Look at lines 483-490 of getpathp.c:
>
>        if (pythonhome == NULL || *pythonhome == '\0') {
>                if (search_for_prefix(argv0_path, LANDMARK))
>                        pythonhome = prefix;
>                else
>                        pythonhome = NULL;
>        }
>        else
>                strncpy(prefix, pythonhome, MAXPATHLEN);
>
> In other words, if PYTHONHOME is set, it's copied into the global
> "prefix" variable, which is where sys.prefix comes from.
>
>
>> It would also seem onWindowsthat everything is based off where the

>> Python DLL is located and that cannot be overridden through
>> configuration that mod_wsgi could set.
>

> Also not true.  The Python standard library is installed under C:
> \Python26, while the DLL is installed into C:\Windows\System32.  The
> only thing the DLL location determines is the python26.zip file
> location; this will be something like C:\Windows
> \System32\python26.zip.
>
> I did my own build of mod_wsgi 2.5, with Python 2.6.2 and Apache
> 2.2.11.  The only thing I changed is that I removed the preprocessor
> directives that disable WSGIPythonHome on Windows.  If I set up a web
> server with this directive:
>
> WSGIPythonHome C:/AltPyLib
>
> I get a sys.path which is akin to this:
>
> C:\WINDOWS\system32\python26.zip
> C:\AltPyLib\DLLs
> C:\AltPyLib\lib
> C:\AltPyLib\lib\plat-win
> C:\AltPyLib\lib\lib-tk
> C:\Program Files\apache\bin
>
> Isn't that exactly what's expected?  Other than maybe the zip file,
> which doesn't exist by default anyway.

FWIW, all the speculation in that discussion was based on me having to
interpret second hand information sent to me by others. Usually those
people didn't know what to look for and could well not have been doing
the correct thing or interpreting the result properly. Part of the
feedback could also have been based on older versions of Python which
possibly may not have worked in exactly the same way for all I know.

It is only recently that I have started building mod_wsgi myself on
Windows and even then I don't really test it on Windows much. Now that
I have the environment, I am in a position to properly research this
issue however, so I will create a ticket to do that. I am not sure
though whether changes will be made for mod_wsgi 3.0 however, depends
on how much time I have.

> Incidentally, I've noticed in this thread a lot of people are
> referencing log output like this:

>
> [Tue Jan 15 16:48:57 2008] [warn] mod_wsgi: Python module path 'C:\
> \WINDOWS\\system32\\python25.zip;C:\\Python25\\Lib;C:\\Python25\
> \DLLs;C:\\Python25\\Lib\\lib-tk;;C:\\Program Files\\Apache Software
> Foundation\\Apache2.2\\bin'.
>

> That output is produced by wsgi_python_version, which is called before
> Py_SetPythonHome; so how could it ever reflect WSGIPythonHome?

Later versions of mod_wsgi than you are using don't output that any
more as it is mostly meaningless anyway, even if Python home was
overridden.

PS. I have sent this back onto list with bcc to you in case you don't
want your details public given you sent me this direct.

Graham

[craighnti]

> FWIW, all the speculation in that discussion was based on me having to
> interpret second hand information sent to me by others. Usually those
> people didn't know what to look for and could well not have been doing
> the correct thing or interpreting the result properly. Part of the
> feedback could also have been based on older versions of Python which
> possibly may not have worked in exactly the same way for all I know.
>

> It is only recently that I have started building mod_wsgi myself onWindowsand even then I don't really test it onWindowsmuch. Now that

> I have the environment, I am in a position to properly research this
> issue however, so I will create a ticket to do that. I am not sure
> though whether changes will be made for mod_wsgi 3.0 however, depends
> on how much time I have.

Thank you for your attention to this. As an interim solution, you
might consider adding a preprocessor symbol that will enable
WSGIPythonHome on Windows (currently it's unconditionally disabled on
Windows).

> PS. I have sent this back onto list with bcc to you in case you don't
> want your details public given you sent me this direct.

And thank you for your concern for my privacy, but I had actually
intended that message for the list; it was sent directly to you
because I generally have no idea what I'm doing with Google Groups.

[Graham Dumpleton]

2009/7/24 craighnti <craig.h...@neurotronics.com>:

>
>> FWIW, all the speculation in that discussion was based on me having to
>> interpret second hand information sent to me by others. Usually those
>> people didn't know what to look for and could well not have been doing
>> the correct thing or interpreting the result properly. Part of the
>> feedback could also have been based on older versions of Python which
>> possibly may not have worked in exactly the same way for all I know.
>>
>> It is only recently that I have started building mod_wsgi myself onWindowsand even then I don't really test it onWindowsmuch. Now that
>> I have the environment, I am in a position to properly research this
>> issue however, so I will create a ticket to do that. I am not sure
>> though whether changes will be made for mod_wsgi 3.0 however, depends
>> on how much time I have.
>
> Thank you for your attention to this.  As an interim solution, you
> might consider adding a preprocessor symbol that will enable
> WSGIPythonHome on Windows (currently it's unconditionally disabled on
> Windows).

This is reenabled in 3.0 trunk. Don't have time nor inclination (cause
I find it ugly working on Windows), to do any real tests of it. I got
as far as setting WSGIPythonHome to C:/cygwin/../Python26 and it still
work but with that value reflected in sys.prefix. It only crashed in
shutdown when I tried referring it to a Python 3.0 installation
instead. :)

Graham