Thanks for your help Jonathan. I was able to get it working. I had to recompile the python in my virtualenv too, with --enable-shared. For reference, the related discussion in modwsgi: https://groups.google.com/d/topic/modwsgi/gQPT3iEwvU8/discussion
On Wednesday, August 1, 2012 7:31:21 PM UTC+2, Daniel Gonzalez wrote: > > Thanks Jonathan, > > I will try this later today. > > Regards, > Daniel > > On Wednesday, August 1, 2012 6:44:24 PM UTC+2, Jonathan Lundell wrote: >> >> On 1 Aug 2012, at 9:30 AM, Daniel Gonzalez <[email protected]> wrote: >> > On Wednesday, August 1, 2012 5:56:37 PM UTC+2, Jonathan Lundell wrote: >> > On 1 Aug 2012, at 8:52 AM, Daniel Gonzalez <[email protected]> wrote: >> >> Quoting from the link you posted: >> >> >> >> "The purpose of such Python virtual environments is to allow one to >> create multiple distinct Python environments for the same version of >> Python, but with different sets of Python modules and packages installed >> into the Python 'site-packages' directory." >> > >> > It (virtualenv) also supports different Python versions. Note later in >> the text where they talk about making sure that your mod_wsgi is built with >> the Python version you're using in the virtualenv. >> > >> > I am not building mod_wsgi: I am installing it with apt-get install. I >> do not know which is the version it was compiled for, since it comes >> pre-packaged with the apache ubuntu distribution. I assume it is the >> system-wide python version (2.6.5). >> > >> > But I need to use the python version in my virtualenv for my web2py >> application (2.7.2). Running *any* python script with *any* python >> interpreter is usually as easy as making sure that the right python >> interpreter is selected, by setting the PATH, and putting "#!/usr/bin/env >> python" on top of the python script. Why is mod_python different in this >> regard? Isn't it basically a wrapper to call the python interpreter? >> >> I'm guessing because it's got some C components, and needs to be compiled >> against the same headers and libraries as the Python binary. >> >> > Do you think there is any chance at all of using the python version in >> my virtualenv without having to recompile mod_wsgi? >> > >> > I am afraid that if I start recompiling mod_wsgi this will prove very >> complicated, and it will even force me to recompile apache ... >> > Besides, what happens if tomorrow I need to upgrade my python version? >> Then I need to recompile mod_wsgi too. Looks complicated :( >> >> I don't see why you'd need to recompile Apache, but yeah, it's a little >> complicated. Here's a discussion: >> http://code.google.com/p/modwsgi/wiki/InstallationIssues >> >> Notice that you don't necessarily have to recompile mod_wsgi for a Python >> patch-level upgrade (third digit). >> >> FWIW, I've done this both ways. Under Ubuntu, I built both Python and >> mod_wsgi to get 2.7.3. When I moved to RHEL, I decided that I could live >> with Python 2.6, and didn't bother with Python (though I did have to >> rebuild mod_wsgi for other reasons). >> >> If you *do* build, I suggest using a tool like Fabric to encapsulate the >> process, so you can repeat it as required. Among other things, that makes >> building new servers or moving to later versions a lot easier. Here's my >> current fab script (note that it's oriented toward RHEL, but the Ubuntu >> details should be similar). The commented-out --with-python option lets you >> specify a non-system Python for the build. >> >> @roles('web') >> def install_wsgi(): >> if env.os == 'rhel': >> e = dict(wsgi_version = '3.3') >> with cd('/tmp'): >> run('wget -nv >> http://modwsgi.googlecode.com/files/mod_wsgi-{wsgi_version}.tar.gz'.format(**e)) >> >> >> run('tar xvfz mod_wsgi-{wsgi_version}.tar.gz'.format(**e)) >> with cd('/tmp/mod_wsgi-{wsgi_version}'.format(**e)): >> #./configure --with-python=/usr/local/bin/python >> run('./configure') >> run('make') >> sudo('make install') >> sudo('echo "LoadModule wsgi_module modules/mod_wsgi.so" > >> {apachedir}/conf.d/wsgi.conf'.format(**env)) >> >> --
