On 15 April 2011 11:47, Paddy Joy <[email protected]> wrote:
> Graham,
>
> Thanks for your help on this, finally got to the bottom of it.
>
> I had set WSGIPythonHome /usr/local/pythonenv/BASELINE in the file /
> etc/apache2/mods-available/wsgi.conf so it wasn't being picked up by
> apache.
>
> Moving it to /etc/apache2/conf.d resolved the issue and I'm now seeing
> the correct path and prefix.

That would only be an issue if wsgi.conf wasn't linked into
mods-enabled directory, or what is in mod-enabled is a copy rather
than symlink and didn't have it listed.

So long as WSGIPythonHome after LoadModule for mod_wsgi it should work.

Graham


> Paddy
>
> On Apr 15, 11:24 am, Paddy Joy <[email protected]> wrote:
>> No mod_python is not installed.
>>
>> Paddy
>>
>> On Apr 15, 10:15 am, Graham Dumpleton <[email protected]>
>> wrote:
>>
>> > Are you still loading mod_python into Apache? That will stop
>> > WSGIPythonHome working as mod_python handles Python interpreter
>> > initialisation when both loaded and certain features of mod_wsgi
>> > crippled as a result.
>>
>> > Graham
>>
>> > On 15 April 2011 10:06, Paddy Joy <[email protected]> wrote:
>>
>> > > Hi Graham,
>>
>> > > Yes when I created the BASELINE I used --no-site-packages.
>>
>> > > I ran a test as described in the docs with WSGIPythonHome /usr/local/
>> > > pythonenv/BASELINE
>>
>> > > but it still shows sys.prefix = /usr
>>
>> > > I also checked /etc/apache2/envvars and there is nothing in there that
>> > > sets the PYTHONPATH
>>
>> > > Any other thoughts on what else I can check?
>>
>> > > Thanks,
>> > > Paddy
>>
>> > > On Apr 15, 8:09 am, Graham Dumpleton <[email protected]>
>> > > wrote:
>> > >> Actually, thinking about it it will always have main Python
>> > >> installation site-packages at the end. This is why it is important to
>> > >> ensure the order things are done is correct.
>>
>> > >> The reason it is still there is that mod_wsgi is still starting up
>> > >> with the main Python installation and all you are doing is adding in
>> > >> the virtual environment site-packages on top of that. When ordering is
>> > >> right, the virtual environment site-packages additions would come
>> > >> earlier in the sys.path and so hide any package of same name in main
>> > >> Python installation site-packages.
>>
>> > >> To totally avoid seeing anything from main Python installations
>> > >> site-packages, you need to create a virtual environment with
>> > >> --no-site-packages and point WSGIPythonHome at it. That way mod_wsgi
>> > >> will use it is as baseline Python installation. You will though when
>> > >> doing this still see that baseline virtual environments site-packages
>> > >> directory listed, but that site-packages directory, if
>> > >> --no-site-packages option works, should be empty and so no chance of
>> > >> picking up packages/modules from the original system wide Python from
>> > >> which the virtual environments are being created.
>>
>> > >> So, when you created baseline for use with WSGIPythonHome, did you use
>> > >> --no-site-packages for it? And was it that baselines site-packages
>> > >> that was listed or the system wide Python installations when using
>> > >> WSGIPythonHome against the virgin baseline?
>>
>> > >> Only other possibilities are that PYTHONPATH is set in environment of
>> > >> user that Apache runs as. That the BASELINE wasn't readable by user
>> > >> Apache runs as and therefore fell back to system wide Python.
>>
>> > >> Do some of the checks in:
>>
>> > >>  http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Python...
>>
>> > >> to validate what sys.prefix is set to and so what Python installation
>> > >> it has used.
>>
>> > >> Graham
>>
>> > >> On 14 April 2011 23:48, Paddy Joy <[email protected]> wrote:
>>
>> > >> > Hi Graham,
>>
>> > >> > Thanks for the reply and spotting the wrong placement of the path
>> > >> > save.
>>
>> > >> > I have tidied up the django.wsgi but I am still seeing the same issue.
>> > >> > django.wsgi is now:
>>
>> > >> > ALLDIRS = ['/usr/local/pythonenv/DJANGO_LEGACY_1.2/lib/python2.5/site-
>> > >> > packages/']
>> > >> > import os, sys, site
>>
>> > >> > # Prev path
>> > >> > print sys.path
>>
>> > >> > prev_sys_path = list(sys.path)
>>
>> > >> > for directory in ALLDIRS:
>> > >> >        site.addsitedir(directory)
>>
>> > >> > new_sys_path = []
>>
>> > >> > for item in list(sys.path):
>> > >> >    if item not in prev_sys_path:
>> > >> >        new_sys_path.append(item)
>> > >> >        sys.path.remove(item)
>> > >> > sys.path[:0] = new_sys_path
>>
>> > >> > sys.path.append('/var/django')
>> > >> > sys.path.append('/var/django/fasttraku')
>>
>> > >> > # New path
>> > >> > print sys.path
>>
>> > >> > os.environ['DJANGO_SETTINGS_MODULE'] = 'fasttraku.settings'
>>
>> > >> > import django.core.handlers.wsgi
>> > >> > application = django.core.handlers.wsgi.WSGIHandler()
>>
>> > >> > Output in apache log shows path at end of django.wsgi still includes
>> > >> > main site-packages:
>>
>> > >> > Original path - [Thu Apr 14 23:26:03 2011] [error] [...........'/usr/
>> > >> > lib/python2.5/site-packages', .......]
>>
>> > >> > Path at end of wsgi script - [Thu Apr 14 23:26:03 2011] [error]
>> > >> > [...........'/usr/local/pythonenv/DJANGO_LEGACY_1.2/lib/python2.5/site-
>> > >> > packages',  '/usr/lib/python2.5/site-packages'....... ]
>>
>> > >> > Intention is that it would not fall back onto system wide site-
>> > >> > packages. The virtual environment "DJANGO_LEGACY_1.2" was created with
>> > >> > --no-site-packages and this can be confirmed by activating from the
>> > >> > command line.
>>
>> > >> > paddy@joytech:/var/django$ source /usr/local/pythonenv/
>> > >> > DJANGO_LEGACY_1.2/bin/activate
>> > >> > (DJANGO_LEGACY_1.2)paddy@joytech:/var/django$ python
>> > >> > Python 2.5.2 (r252:60911, Jan 20 2010, 23:14:04)
>> > >> > [GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2
>> > >> > Type "help", "copyright", "credits" or "license" for more information.
>> > >> >>>> import sys; print sys.path
>> > >> > ['', '/usr/local/pythonenv/DJANGO_LEGACY_1.2/lib/python2.5/site-
>> > >> > packages/django_registration-0.7-py2.5.egg', '/usr/local/pythonenv/
>> > >> > DJANGO_LEGACY_1.2/lib/python2.5/site-packages/setuptools-0.6c11-
>> > >> > py2.5.egg', 
>> > >> > '/usr/local/pythonenv/DJANGO_LEGACY_1.2/lib/python2.5/site-
>> > >> > packages/pip-1.0-py2.5.egg', '/usr/local/pythonenv/DJANGO_LEGACY_1.2/
>> > >> > lib/python25.zip', '/usr/local/pythonenv/DJANGO_LEGACY_1.2/lib/
>> > >> > python2.5', 
>> > >> > '/usr/local/pythonenv/DJANGO_LEGACY_1.2/lib/python2.5/plat-
>> > >> > linux2', '/usr/local/pythonenv/DJANGO_LEGACY_1.2/lib/python2.5/lib-
>> > >> > tk', '/usr/local/pythonenv/DJANGO_LEGACY_1.2/lib/python2.5/lib-
>> > >> > dynload', '/usr/lib/python2.5', '/usr/lib64/python2.5', '/usr/lib/
>> > >> > python2.5/plat-linux2', '/usr/lib/python2.5/lib-tk', '/usr/lib64/
>> > >> > python2.5/lib-tk', '/usr/local/pythonenv/DJANGO_LEGACY_1.2/lib/
>> > >> > python2.5/site-packages', '/usr/local/pythonenv/DJANGO_LEGACY_1.2/lib/
>> > >> > python2.5/site-packages/PIL']
>>
>> > >> > I have also tried creating a BASELINE virgin environment and adding
>> > >> > WSGIPythonHome /usr/local/pythonenv/BASELINE to apache config as
>> > >> > described in your docs but I still see the same behaviour.
>>
>> > >> > Has me stumped.
>>
>> > >> > Paddy
>>
>> > >> > On Apr 14, 8:36 pm, Graham Dumpleton <[email protected]>
>> > >> > wrote:
>> > >> >> On 14 April 2011 00:13, Paddy Joy <[email protected]> wrote:
>>
>> > >> >> > Hi,
>>
>> > >> >> > I have attempted to set up a virtualenv to run some applications 
>> > >> >> > using
>> > >> >> > django 1.2.5. From the command line everything appears to be ok
>> > >> >> > however when I run the application using mod_wsgi daemon mode I am
>> > >> >> > getting conflicting versions of site-packages in sys.path.
>>
>> > >> >> Have you tried using --no-site-packages to virtualenv, or do you 
>> > >> >> still
>> > >> >> want fallback to base Python installation?
>>
>> > >> >> Anyway, see real reason for problem below.
>>
>> > >> >> > Config:
>>
>> > >> >> > Django 1.25 in 
>> > >> >> > /usr/local/pythonenv/DJANGO_LEGACY_1.2/lib/python2.5/
>> > >> >> > site-packages/django
>> > >> >> > Django svn in /usr/lib/python2.5/site-packages/django
>>
>> > >> >> > django.wsgi
>>
>> > >> >> > import os, sys, site
>>
>> > >> >> > site.addsitedir('/usr/local/pythonenv/DJANGO_LEGACY_1.2/lib/python2.5/
>> > >> >> > site-packages')
>>
>> > >> >> You have this in the wrong spot. See:
>>
>> > >> >>  http://code.google.com/p/modwsgi/wiki/VirtualEnvironments
>>
>> > >> >> You are meant to save away sys.path before calling site.addsitedir().
>>
>> > >> >> > prev_sys_path = list(sys.path)
>>
>> > >> >> > sys.path.append('/var/django')
>> > >> >> > sys.path.append('/var/django/fasttraku')
>> > >> >> > sys.path.append('/var/django/debug_toolbar')
>>
>> > >> >> > new_sys_path = []
>>
>> > >> >> > for item in list(sys.path):
>> > >> >> >    if item not in prev_sys_path:
>> > >> >> >        new_sys_path.append(item)
>> > >> >> >        sys.path.remove(item)
>> > >> >> > sys.path[:0] = new_sys_path
>>
>> > >> >> > os.environ['DJANGO_SETTINGS_MODULE'] = 'fasttraku.settings'
>>
>> > >> >> > import django.core.handlers.wsgi
>> > >> >> > application = django.core.handlers.wsgi.WSGIHandler()
>>
>> > >> >> > print sys.path
>>
>> > >> >> > The output of print.sys shows:
>> > >> >> > ['/usr/local/pythonenv/DJANGO_LEGACY_1.2/lib/python2.5/site-
>> > >> >> > packages', ........... '/usr/lib/python2.5/site-packages']
>>
>> > >> >> > When operating from the command line the virtualenv sys.path 
>> > >> >> > doesn't
>> > >> >> > include '/usr/lib/python2.5/site-packages' and everything works as
>> > >> >> > expected but when running through the mod_wsgi daemon both paths 
>> > >> >> > are
>> > >> >> > included which causes the wrong versions of packages to be 
>> > >> >> > imported.
>>
>> > >> >> > Any ideas what I am doing wrong?
>>
>> > >> >> > Paddy
>>
>> > >> >> > --
>> > >> >> > You received this message because you are subscribed to the Google 
>> > >> >> > Groups "modwsgi" group.
>> > >> >> > To post to this group, send email to [email protected].
>> > >> >> > To unsubscribe from this group, send email to 
>> > >> >> > [email protected].
>> > >> >> > For more options, visit this group 
>> > >> >> > athttp://groups.google.com/group/modwsgi?hl=en.
>>
>> > >> > --
>> > >> > You received this message because you are subscribed to the Google 
>> > >> > Groups "modwsgi" group.
>> > >> > To post to this group, send email to [email protected].
>> > >> > To unsubscribe from this group, send email to 
>> > >> > [email protected].
>> > >> > For more options, visit this group 
>> > >> > athttp://groups.google.com/group/modwsgi?hl=en.
>>
>> > > --
>> > > You received this message because you are subscribed to the Google 
>> > > Groups "modwsgi" group.
>> > > To post to this group, send email to [email protected].
>> > > To unsubscribe from this group, send email to 
>> > > [email protected].
>> > > For more options, visit this group
>>
>> ...
>>
>> read more »
>
> --
> You received this message because you are subscribed to the Google Groups 
> "modwsgi" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to 
> [email protected].
> For more options, visit this group at 
> http://groups.google.com/group/modwsgi?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"modwsgi" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/modwsgi?hl=en.

Reply via email to