|Summary:||www-apache/mod_wsgi lacks a way to specify which python version to use|
|Product:||Gentoo Linux||Reporter:||Giampaolo Tomassoni <giampaolo>|
|Component:||[OLD] Server||Assignee:||Dirkjan Ochtman <djc>|
|Severity:||normal||CC:||devurandom, gentoo, kensington|
|Package list:||Runtime testing required:||---|
|Attachments:||Patch enabling PYTHON_SINGLE_TARGET|
Description Giampaolo Tomassoni 2013-01-03 16:42:34 UTC
mod_wsgi can only run the python interpreter version specified at configure-time (via --with-python=/path/to/python option). Actually, this module doesn't avail of any USE flag to specify the python version to use (i.e.: no python2/python3 flags available), instead relying on the current default python interpreter as selected via eselect. I discovered this limit deploying the www-apps/viewvc-1.1.17 sccs viewer, which is actually stuck to python-2 while my system uses python-3 as default interpeter. I had to clone the stock www-apache/mod_wsgi-3.4 ebuilt to my own dirty overlay and then hardly tweak it to only detect python-2... Reproducible: Always Steps to Reproduce: 1.eselect python set python3.2 2.USE=mod_wsgi emerge www-apps/viewvc 3.try to run viewvc via mod_wsgi Actual Results: It doesn't work since viewvc code is not compatible with python3. Expected Results: emerging www-apps/viewvc with mod_wsgi should emerge www-apache/mod_wsgi with a suitable python interpreter (which is, python 2.x).
Comment 1 Michael Palimaka (kensington) 2013-05-22 18:59:27 UTC
This could be achieved using the new python eclasses.
Comment 2 Joe Breuer 2013-06-25 17:40:13 UTC
Created attachment 351938 [details, diff] Patch enabling PYTHON_SINGLE_TARGET Attached is a very simplistic straight-forward patch to the ebuild to use the python-single-r1 eclass, thus enabling the PYTHON_SINGLE_TARGET mechanism to work for mod_wsgi. The patched ebuild "works for me", allowing mozilla-sync-server (which insists on python 2) to run "unsuspiciously" on a system with both python-2.7.3 and python-3.2.3 installed, and python-3.2.3 being the system python instance (i.e. that's what the unmodified ebuild used).
Comment 3 Giampaolo Tomassoni 2013-07-04 18:44:08 UTC
Joachim's patch works for me. +1
Comment 4 Ondrej Grover 2013-07-09 18:16:30 UTC
I've tested the patch and it works well, finally a convenient way to get Trac and other python2 stuff running without switching the main python version. On another note, perhaps it would be possible to install two versions of the mod , each compiled with the python version in PYTHON_TARGETS. I'm just not sure how to do it, perhaps subslots based on the python version? Essentially it's just one *.so file, so that could be easily renamed to reflect the version and the 70_mod_wsgi.conf would be just slightly modified, e.g. to use `-D WSGI_PYTHON2`
Comment 5 Giampaolo Tomassoni 2013-07-10 20:54:43 UTC
Frankly, I don't see any advantage in allowing a working mod_wsgi module (the one compiled against python2) to coexist with a non-working one (the one compiled against python3). The fix we got via this bug is meant to circumvent an upstream limit (mod_wsgi only working with python2), not to enhance the gentoo package.
Comment 6 Ondrej Grover 2013-07-11 14:14:34 UTC
(In reply to Giampaolo Tomassoni from comment #5) I'm not sure what you mean by the version compiled against python3 "not working". If you mean that it wouldn't be usable with python2 apps, I wouldn't call that "not working", some people may have python3 apps too. If we could have both, we could select against which versions we want it to be compiled through PYTHON_TARGETS and if you want only python2, set the var accordingly, other people can use mod_wsgi for both python2 and python3 apps.
Comment 7 Giampaolo Tomassoni 2013-07-11 20:11:03 UTC
(In reply to Ondrej Grover from comment #6) Well, you're right: I'm using mod_wsgi only with viewvc, which is ultimately the culprit of the python3 idiosincrasy. Anyway, I see my mod_wsgi.so do actually links against libpython2.7.so.1.0. So, if you would like to have two different mod_wsgi.so libraries, each linking to a different python version and then instantiate both them in the very same apache process, well, maybe there will be troubles: since mod_wsgi doesn't use dlopen to load the python libraries, there would probably be some kind of symbol clash loading both python libraries.
Comment 8 Dennis Schridde 2013-10-14 16:34:12 UTC
(In reply to Joachim Breuer from comment #2) > Created attachment 351938 [details, diff] [details, diff] > Patch enabling PYTHON_SINGLE_TARGET Patch works here, too. Would be nice, if it could be integrated into the Gentoo ebuild.
Comment 9 Dirkjan Ochtman 2013-10-15 09:54:40 UTC
Thanks to Joachim for the patch, and everyone for testing it. I've now incorporated it into 3.4-r1, in the tree now. Sorry for taking so long! 15 Oct 2013; Dirkjan Ochtman <email@example.com> -mod_wsgi-3.3.ebuild, +mod_wsgi-3.4-r1.ebuild: Remove old version, support python-single-r1 (bug 450022, thanks to Joachim Breur <firstname.lastname@example.org> for the patch).