2008/11/4 Max Ischenko <[EMAIL PROTECTED]>: >> If you are merely trying to have one appear at a sub URL context of >> the other, but there is no interaction between the two, you would be >> better off mounting them as separate WSGI applications at >> Apache/mod_wsgi level rather than trying to use Pylons feature to do >> the same. Benefit of this is that they can run in separate sub >> interpreters or even daemon processes and thus not interfere with each >> other. >> >> Only reasons can think to using Pylons to composite them together is >> if one is providing session management for the other to get SSO, or if >> WSGI middleware being used to modify the response of the other. > > Yup, that's the idea. I want common user auth. > May be I should re-think this and let them run separatedly.
Unfortunately Python web application frameworks are not very well developed in the area of cross application single sign on. There expectation is that WSGI should be used to combine them within one process, but that isn't necessarily practical. Anyway, that is for form based login mechanism. If you are only interested in HTTP Basic or Digest authentication, that can be delegated back up to Apache. In Apache 2.4 there is a mod_session module which should help with single sign on across distinct applications, but not sure how successful at this point I will be in pushing various WSGI frameworks to work in such a way that would be compatible with it. > There is also issue of url mapping. Say I want /foo and /bar to be > mapped to my django app, while / and /quux to my pylons app. Is it > possible? Intermingling URLs from two applications is reasonably straight forward with mod_wsgi. Ignoring '/quux' to start with, to have one be mounted at root, and then specific sub URLs directed to another use: WSGIScriptAliasMatch ^/(foo|bar)(/.*)?$ /some/path/django.wsgi/$1$2 WSGIScriptAlias / /some/path/pylons.wsgi The first is done using WSGIScriptAliasMatch in on line so don't have to override what sub interpreter is used and to avoid having to do some fiddles in WSGI script file. Something similar was covered recently in: http://groups.google.com/group/modwsgi/browse_frm/thread/86d3dda6392da97c As is the above will send /foo and /bar to Django and everything else to Pylons. Now we get to /quux. If you meant that only '/', rather than everything under it, and '/quux', need to work out how to combine them into one pattern. This is a bit more tricky as we don't want to match trailing URL component for '/'. I'll have to do some playing with that and get back to you, as can't get my head around it right now. :-) >> Was this virtual environment created with --no-site-packages or is it >> chained off main Python installation and therefore inheriting >> packages/modules from main Python installation as well. >> >> If chained off main Python installation, are there versions of >> packages/modules in main Python installation site-packages directory >> which are also separately installed in the virtual environment. > > It was created with simple "virtualenv py" command, no extra args. Probably no drama if not using --no-site-packages, as long as only used with WSGIPythonHome and not also using WSGIPythonPath or python-path option to add extra directories. The virtual environment documentation: http://code.google.com/p/modwsgi/wiki/VirtualEnvironments talks about using --no-site-packages mainly because when using site.addsitedir() explicitly it adds new directories at end, so if trying to override those in main Python installation site-packages, will not work as expected if --no-site-packages wasn't used to completely isolate it from main Python installation. WSGIPythonPath and python-path also just call site.addsitedir() so also an issue there, although in mod_wsgi 3.0 that is addressed by doing some sys.path reordering. http://code.google.com/p/modwsgi/issues/detail?id=112 >> This is what I don't understand. The entry point is the Django >> application. How does the Pylons application get mapped into URL >> namespace or invoked? > > It is not. :) > I was planning to use paste's URL composite middleware but stuck with > the error above. > > I added assertion about django.settings after pylons app, it still > passes. > > I added these lines as well: > > print >> sys.stderr, "#1 %s" % doudj.settings.__file__ > print >> sys.stderr, "#2 %s" % dir(doudj) > print >> sys.stderr, "#3 %s" % dir(doudj.settings) > print >> sys.stderr, "#4 %s" % doudj.settings.ROOT_URLCONF > > It correctly prints out #4 doudj.urls > %) > > And then I get AttributeError: 'module' object has no attribute > 'ROOT_URLCONF' > > I suppose DJango somehow somewhere finds _other_ settings.py Django settings are lazily imported and so if Pylons is somehow stuffing with sys.path or doing other funny things, it might not be getting loaded when Django actually triggered. Suggest try the following: heredir = os.path.dirname(__file__) sys.path.insert(0, heredir) os.environ['DJANGO_SETTINGS_MODULE'] = 'doudj.settings' import doudj.settings assert doudj.settings.ROOT_URLCONF, doudj.settings from django.core.handlers.wsgi import WSGIHandler # ADD import django.conf django.conf.settings._import_settings() import sys print >> sys.stderr, django.conf.settings._target.__name__ print >> sys.stderr, django.conf.settings._target.__file__ print >> sys.stderr, dir(django.conf.settings._target) # END django_app = WSGIHandler() from paste.deploy import loadapp doupy_app = loadapp('config:config.ini', relative_to=os.path.join(heredir, 'doupy')) application = django_app I think this will force import settings module before Pylons configured. If that works, then perhaps move it after Pylons initialisation and see what is different. Graham --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
