As per:
http://code.google.com/p/modwsgi/wiki/VirtualEnvironments
if you had used:
ALLDIRS = ['usr/local/pythonenv/PYLONS-1/lib/python2.5/site-packages']
import sys
import site
# Remember original sys.path.
prev_sys_path = list(sys.path)
# Add each new site-packages directory.
for directory in ALLDIRS:
site.addsitedir(directory)
# Reorder sys.path so new directories at the front.
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
which does the reordering, you wouldn't have the issue and shouldn't
need to clear sys.path.
Better still just use:
activate_this = '/usr/local/pythonenv/PYLONS-1/bin/activate_this.py'
execfile(activate_this, dict(__file__=activate_this))
which also does the reordering.
Ignore any warnings in there about sys.prefix being overridden as
still not seeing any issues with that.
Graham
On 6 October 2011 10:22, GuyBowden <[email protected]> wrote:
> The rest of the configuration is basically this:
>
> WSGIScriptAlias / /home/admin/domains/mydomain.com/scripts/django.wsgi
>
> <Directory /home/admin/domains/mydomain.com/scripts>
> Order allow,deny
> Allow from all
> </Directory>
>
> Then in my django.wsgi file I have this:
>
> import os
> import sys
> import site
>
> # hacky removal and re-instatement of system wide sys paths
> sys.path = ['/home/admin/domains/v2-doorstepskis.com/dssV2/scripts', '/
> usr/local/lib/python25.zip', '/usr/local/lib/python2.5', '/usr/local/
> lib/python2.5/plat-linux2', '/usr/local/lib/python2.5/lib-tk', '/usr/
> local/lib/python2.5/lib-dynload']
>
> # these add on to the end of the sys.path
> site.addsitedir('/usr/local/pythonenv/BASELINE/lib/python2.5/site-
> packages/')
> site.addsitedir('/home/admin/domains/mydomain.com/ENV/lib/python2.5/
> site-packages/')
>
> os.environ['DJANGO_SETTINGS_MODULE'] = 'dssV2.settings'
>
> path = '/home/admin/domains/mydomain.com'
> if path not in sys.path:
> sys.path.append(path)
> sys.path.append(path+'/dssV2')
>
> import django.core.handlers.wsgi
> application = django.core.handlers.wsgi.WSGIHandler()
>
> Obviously this isn't a great solution. But it should allow me to
> transfer the sites over to mod_wsgi and each one their own virtualenv
> - then I can unload mod_python and the PythonHome directive should
> start working...
>
> Then remove the sys.path reset hack from each one...
>
> On Oct 6, 12:56 am, Graham Dumpleton <[email protected]>
> wrote:
>> You shouldn't need to clear sys.path out and doing so is possibly not
>> a good idea.
>>
>> So long as you are doing things the right way by using methods that do
>> path reordering, then any paths from the virtual environment would be
>> added at the start of sys.path and so would take precedence over the
>> system wide ones. Thus would not matter if older Django installed in
>> system wide Python as that in virtual environment would be found
>> first.
>>
>> As I said before, since though you didn't explain how you were doing
>> the rest of the configuration I cant really help you and point out
>> what was originally wrong.
>>
>> Graham
>>
>> On 6 October 2011 09:45, GuyBowden <[email protected]> wrote:
>>
>>
>>
>>
>>
>>
>>
>> > Hmmm - solved for now by clearing sys.path in my django.wsgi file and
>> > running addsitedir on my baseline site-packages and my site specific
>> > site-packages
>>
>> > If it ignores the PythonHome directive, then it's obviously loading up
>> > the sys path from the server wide python site-packages - including the
>> > older version of Django etc. So clearing it works for me for now.
>>
>> > Thanks,
>>
>> > Guy
>>
>> > On Oct 5, 11:23 pm, Graham Dumpleton <[email protected]>
>> > wrote:
>> >> On 6 October 2011 08:13, GuyBowden <[email protected]> wrote:
>>
>> >> > I am still using mod_python as there are live sites on the apache
>> >> > server using it...
>>
>> >> > I created the virtualenv with "--no-site-packages" at the location
>> >> > specified (as explained in my post) - not blindly copying the example
>> >> > - I do understand what it does.
>>
>> >> > I did not know that mod_python and mod_wsgi couldn't live happily
>> >> > together on the same apache instance - hence the question.
>>
>> >> > Now I know that, I can carry on. Thanks for answering.
>>
>> >> Then you will need to ensure you use method that does sys.path
>> >> reordering properly. Likely picking up old Django version from system
>> >> wide Python at the moment. Older versions don't have csrf support.
>>
>> >> Since you didn't provide information about whether using
>> >> embedded/daemon mode and what else you are doing besides
>> >> WSGIPythonHome can't say what you need to change.
>>
>> >> Graham
>>
>> >> > Guy
>>
>> >> > On Oct 5, 10:42 pm, Graham Dumpleton <[email protected]>
>> >> > wrote:
>> >> >> Are you still loading mod_python into the same Apache?
>>
>> >> >> WSGIPythonHome is ignored if mod_python also being loaded as
>> >> >> mod_python is initialising Python and not mod_wsgi.
>>
>> >> >> That or you didn't use --no-site-packages when creating virtual
>> >> >> environment referred to by WSGIPythonHome and also didn't do sys.path
>> >> >> reordering in WSGI script if didn't use configuration directives to
>> >> >> adding additional virtual environment path.
>>
>> >> >> Explain whether you are using embedded mode or daemon mode.
>>
>> >> >> Explain whether you actually created a Python virtual environment at
>> >> >> the location specified by WSGIPythonHome or whether you just blindly
>> >> >> copied the example without understanding what it did.
>>
>> >> >> Explain which method you then used to tell your Python web application
>> >> >> where your actual virtual environment site-packages directory was
>> >> >> located.
>>
>> >> >> Graham
>>
>> >> >> On 6 October 2011 06:55, GuyBowden <[email protected]> wrote:
>>
>> >> >> > Hi,
>>
>> >> >> > I am just starting to move from mod_python to mod_wsgi and am also
>> >> >> > setting up virtualenvs for my projects (several running from one
>> >> >> > apache server)
>>
>> >> >> > I set up a virgin virtual env to use as the base env - each site will
>> >> >> > then have it's own virtualenv
>>
>> >> >> > I have put this into my httpd.conf file
>>
>> >> >> > WSGIPythonHome /usr/local/pythonenv/BASELINE
>>
>> >> >> > But it doesn't seem to have any effect - I am getting an django
>> >> >> > import
>> >> >> > error that's coming from my server wide python directory:
>>
>> >> >> > [Wed Oct 05 21:41:41 2011] [error] [client 80.119.239.216] File "/
>> >> >> > usr/local/lib/python2.5/site-packages/django/core/handlers/base.py",
>> >> >> > line 42, in load_middleware
>> >> >> > [Wed Oct 05 21:41:41 2011] [error] [client 80.119.239.216] raise
>> >> >> > exceptions.ImproperlyConfigured, 'Error importing middleware %s:
>> >> >> > "%s"'
>> >> >> > % (mw_module, e)
>> >> >> > [Wed Oct 05 21:41:41 2011] [error] [client 80.119.239.216]
>> >> >> > ImproperlyConfigured: Error importing middleware
>> >> >> > django.middleware.csrf: "No module named csrf"
>>
>> >> >> > This error is because I need to use Django1.3 on the site causing the
>> >> >> > error - I know that, but the file causing it is from my server wide
>> >> >> > python install - not from any virtualenv? I am expecting an import
>> >> >> > error because I've not even setup any versions of Django yet!
>>
>> >> >> > Why might Apache / mod_wsgi be ignoring the PythonHome directive? how
>> >> >> > could I find out further? I don't get any errors on an apache
>> >> >> > restart..
>>
>> >> >> > Thanks,
>>
>> >> >> > Guy
>>
>> >> >> > --
>> >> >> > 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
>> > 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 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.