water pitcher filter change and deep clean
* * *
I left off on 1/6 ~ 1/7 with mod_wsgi "installed" in some sense, but without XAMPP's Apache knowing where to look when it encounters a WSGI script. Which, for our purposes moving forward, is any .py script.
I was a put off for a while by the not-very-direct instructions to supply Apache with a configuration directive to find the mod_wsgi module. Today I did a careful read of Graham Dumpleton's mod_wsgi "readme" and found the magic.
With mod_wsgi installed via Python's pip facility, at any DOS prompt you should be able to
mod_wsgi-express module-config
...For me this returned
LoadModule wsgi_module "C:/proggies/python/lib/site-packages/mod_wsgi/server/mod_wsgi.cp310-win_amd64.pyd"
WSGIPythonHome "C:/proggies/python"
Per Dumpleton's instructions, that's what you need to add to Apache's httpd.conf (in the same region as the other LoadModule directives).
After the httpd.conf update, XAMPP's control panel was able to stop, but not restart Apache. Suspecting a mismatch between httpd.conf's convention of forward slashes to process directory structure vs. Windows's backslash convention, I flipped the (*nix) slashes to (Windows) backslashes in the new directive lines, saved and tried restarting Apache again.
XAMPP control panel still reported "Apache shutdown unexpectedly", so I tried copying
[...]\python\[...]\mod_wsgi.cp310-win_amd64.pyd
... to ...
[...]\xampp\apache\modules\mod_wsgi.pyd
Correspondingly, I rewrote the LoadModule directive as
LoadModule wsgi_module modules/mod_wsgi.pyd
... and tried restarting Apache again.
Still no luck ... I commented out both of the new directives just to see if maybe something else was botched about my httpd.conf. Apache started successfully so definitely one or both of the two new directives was the problem.
Switching to another Windows user, I noted that Python would not run from the command line there, so switched back to my admin login and reinstalled Python "for all users". A "just for me" installation, regardless of location, could be blamed for not letting a service account (in this case, Apache) use it. Switched back to the other user login to test it, and it worked as expected.
For safety, I also did
: pip uninstall mod_wsgi
: set MOD_WSGI_APACHE_ROOTDIR=c:/xampp/apache
: pip install mod_wsgi
Circling back to twiddle httpd.conf, what I had now looked like:
LoadModule wsgi_module modules/mod_wsgi.pyd
WSGIPythonHome "C:\proggies\python"
Voila, now Apache started fine with no warnings. Progress.
Fom this point on, let it be assumed that each httpd.conf edit was followed by an Apache restart.
However, with the new directives enabled, the server didn't respond to browser requests.
new directives disabled, localhost/test-php/index.php ... yup
new directives enabled, localhost/test-php/index.php .... nope
LoadModule mod_wsgi disabled but WSGIPythonHome enabled ... Apache doesn't start
LoadModule enabled but WSGIPythonHome disabled:
... WSGIPythonHome is necessary "where the Python executable is not in the PATH of the user that Apache runs as". By inference from my informal test running Python at the command line under a different user login, maybe we can get away with no WSGIPythonHome directive in httpd.conf?
- Apache starts; localhost/test-php/index.php hangs and never loads
If mod_wsgi.pyd needs any support files, well, I didn't copy anything else from the Python subfolder into apache/modules, so can I get Apache to start while pointing that LoadModule directive to the original location? For safety's sake I deleted apache/modules/mod_wsgi.pyd
Circling back to Dumpleton's instructions, I realized that
: mod_wsgi-express module-config
... returned an additional directive that I'd perhaps overlooked?
LoadFile "C:/proggies/python/python311.dll"
LoadModule wsgi_module "C:/proggies/python/[...]/mod_wsgi.cp311-win_amd64.pyd"
WSGIPythonHome "C:/proggies/python"
Rather than going off-script again, I pasted all 3 directive lines into httpd.conf
- Apache loaded fine.
- Browsing to http://localhost/test-php/index.php worked as intended. ("Congratulations, PHP works.")
- Browsing to http://localhost/test-wsgi/wsgi.py rendered the script file content as text. ... sigh
In my early Python CGI experimenting, I added 2 lines at the end of httpd.conf, which I later disabled because I figured they would likely interfere with WSGI configuration:
#AddHandler cgi-script .py
#ScriptInterpreterSource Registry-Strict
Just for shiggles I re-enabled them now and tried localhost/test-wsgi/wsgi.py again. Nothing changed, Apache still served the wsgi.py file content as text.
So I disabled those lines in http.conf again, and tried browsing to a copy of wsgi.py named wsgi.wsgi. Still served/rendered as plain text.