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 (RETIRED) <djc> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | dschridde+gentoobugs, gentoo, kensington |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Patch enabling PYTHON_SINGLE_TARGET |
Description
Giampaolo Tomassoni
2013-01-03 16:42:34 UTC
This could be achieved using the new python eclasses. 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).
Joachim's patch works for me. +1 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` 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. (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. (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. (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. 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 <djc@gentoo.org> -mod_wsgi-3.3.ebuild, +mod_wsgi-3.4-r1.ebuild: Remove old version, support python-single-r1 (bug 450022, thanks to Joachim Breur <gentoo@jmbreuer.net> for the patch). |